Global Technology Audit Guide (GTAG)

Written in straightforward business language to address a timely issue related to IT management, control, and security, the
GTAG series serves as a ready resource for chief audit executives on different technology-associated risks and recommended
practices.

Information Technology Controls: Information Technology Outsourcing:

Topics discussed include IT control Discusses how to choose the right IT
concepts, the importance of IT controls, )NFORMATION
4ECHNOLOGY
/UTSOURCING outsourcing vendor and key outsourcing
the organizational roles and control considerations from the client’s
responsibilities for ensuring effective IT and service provider’s operation.
controls, and risk analysis and
monitoring techniques.

Change and Patch Management

Auditing Application Controls:
Controls: Describes sources of change
Change and Patch Addresses the concept of application
Management Controls:
and their likely impact on business Auditing
control and its relationship with general
Critical for
Organizational Application

objectives, as well as how change and

Success
Controls

controls, as well as how to scope a risk-

patch management controls help
based application control review.
manage IT risks and costs and what
works and doesn’t work in practice.

Continuous Auditing: Addresses the Identity and Access Management:

Continuous Auditing:
role of continuous auditing in today’s Covers key concepts surrounding identity
internal audit environment; the Identity and Access
Implications for Assurance,

and access management (IAM), risks

Monitoring, and Management
Risk Assessment

relationship of continuous auditing, associated with IAM process, detailed

continuous monitoring, and continuous guidance on how to audit IAM processes,
assurance; and the application and and a sample checklist for auditors.
implementation of continuous auditing.

Management of IT Auditing: Discusses Business Continuity Management:

IT-related risks and defines the IT audit Defines business continuity management
Management of IT Auditing
universe, as well as how to execute and Business Continuity
Management
(BCM), discusses business risk, and
manage the IT audit process. includes a detailed discussion of BCM
program requirements.

Managing and Auditing Privacy Risks: Developing the IT Audit Plan: Provides
Discusses global privacy principles and step-by-step guidance on how to develop
Managing
and Auditing
Privacy Risks
frameworks, privacy risk models and an IT audit plan, from understanding the
controls, the role of internal auditors, top business, defining the IT audit universe,
10 privacy questions to ask during the and performing a risk assessment, to
course of the audit, and more. formalizing the IT audit plan.

Managing and Auditing IT

Vulnerabilities: Among other topics,
Managing and Auditing
IT Vulnerabilities discusses the vulnerability management
life cycle, the scope of a vulnerability
management audit, and metrics to
measure vulnerability management
practices.

For more information and resources regarding technology related audit guidance,
visit www.theiia.org/technology.
 Global Technology Audit Guide (GTAG®)12:
Auditing IT Projects

Authors

Karine Wegrzynowicz, Lafarge SA

Steven Stein, Hewlett-Packard

March 2009

Copyright © 2009 by The Institute of Internal Auditors, 247 Maitland Avenue, Altamonte Springs,Fla.,
32701-4201. All rights reserved. Printed in the United States of America. No part of this publication may be
reproduced, stored in a retrieval system, or transmitted in any form by any means — electronic, mechanical,
photocopying, recording, or otherwise — without prior written permission from the publisher.

The IIA publishes this document for informational and educational purposes. This document is intended
to provide information, but is not a substitute for legal or accounting advice. The IIA does not provide
such advice and makes no warranty as to any legal or accounting results through its publication of this
document. When legal or accounting issues arise, professional assistance should be retained.
 Table of Contents
Letter from the IIA’s President ................................................................................................................ 1

1. Executive Summary ............................................................................................................................................ 2

2. Introduction.......................................................................................................................................................... 3
2.1 What Exactly Is an IT Project?.................................................................................................................................... 3
2.2 Understanding the Impact........................................................................................................................................... 3
2.3 Examples of Failed IT Projects.................................................................................................................................... 3
2.4 Historical Statistics on IT Project Success and Failure............................................................................................... 3
2.5 Top 10 Factors for Project Success.............................................................................................................................. 4
2.6 Purpose and Benefits of Internal Audit Involvement................................................................................................. 5

3. Five Key Focus Areas for Project Audits............................................................................................. 6

3.1 Business and IT Alignment ........................................................................................................................................ 6
3.2 Project Management . ................................................................................................................................................. 6
3.3 IT Solution Readiness .............................................................................................................................................. 11
3.4 Organizational and Process Change Management . ................................................................................................. 12
3.5 Post Implementation................................................................................................................................................. 13

4. Project Audit Planning ............................................................................................................................... 14

4.1 IT Projects and the Annual Internal Audit Plan . ................................................................................................... 14
4.2 Internal Auditing’s Role............................................................................................................................................ 15
4.3 Types of Project Audits............................................................................................................................................. 16
4.4 External Auditor Considerations.............................................................................................................................. 17

Appendix A – Project Management..........................................................................................................18

A.1 Project Management Methodologies................................................................................................................... 18
A.2 Project Management Life Cycle.......................................................................................................................... 18

Appendix B – IT Project Stakeholders...................................................................................................19

Appendix C – Project Management Offices’ Structure, Roles, and Responsibilities ....20

Appendix D – Maturity Models..................................................................................................................21

D.1 Capability Maturity Model.................................................................................................................................. 21
D.2 Project Management Maturity Models................................................................................................................ 21
D.3 Systems Development Maturity Models.............................................................................................................. 21

Appendix E – General Project Management Best Practices.......................................................22

E.1 PMBOK and PRINCE2....................................................................................................................................... 22
E.2 ISO Standards...................................................................................................................................................... 22
E.3 COBIT Sections That Apply To Project Management...................................................................................... 23
E.4 VAL IT................................................................................................................................................................ 25

Appendix f – Internal Auditor’s Questions for Reviewing an IT Project..........................24

About the Authors.......................................................................................................................................34

 Letter from The IIA’s President

As is true for most internal auditors of my generation, I have witnessed technology’s remarkable evolution from
a ringside seat. When I was a young, newly minted internal auditor directly out of college in the 1970s, the most
complex technology I regularly encountered was a 10-key calculator. Today, though, we live and work in quite a
different world.
Thanks to unrelenting IT advancement since I entered the workforce, virtually everything we encounter now
is embedded with technology. Regardless of the industry or enterprise, information technology is critical to main-
taining a competitive edge, managing risks, and achieving business objectives; and organizations worldwide are
allocating vast resources to vital IT projects.
Whether IT projects are developed inhouse or are co-sourced with third-party providers, they are fraught with
challenges that must be considered carefully to ensure success. Less than desirable outcomes can result from such
issues as poorly defined project scope and objectives, lack of senior manager support, insufficient user involvement,
incorrect or inappropriate technology choices, or lack of knowledge about changing technologies. Insufficient
attention to these and other IT challenges will result in wasted money and resources, loss of trust, and reputation
damage — all of which are huge risks and none of which is acceptable.
Inherent in information technology is its cross-functionality. It must involve people and processes throughout
an organization. And because of the internal auditors’ unique perspective and positioning within their organiza-
tion, their early involvement can help ensure positive results and the accompanying benefits. They can serve as a
bridge between individual business units and the IT function, point out previously unidentified risks, and recom-
mend controls for enhancing outcomes.
For all of these reasons, I am especially pleased with the release of The IIA’s new GTAG: Auditing IT Projects.
This timely guidance provides an overview of techniques for effectively engaging with project teams and manage-
ment to assess the risks related to IT projects. This Practice Guide includes:

• How to outline a framework for assessing project-related risks.

• Key project management risks.
• How the internal audit activity can actively participate in the review of projects while maintaining
independence.
• Five key components of IT projects for internal auditors to consider when building an audit approach.
• Top 10 reasons for project success.
• Types of project audits.
• A sample audit work program with a suggested list of questions for use in the IT project assessment.

The development of this Practice Guide truly was a team effort. We are grateful to The IIA’s Advanced
Technology Committee for selecting the topic and developing the guidance. We owe a great debt of gratitude
to the two principal authors, Karine Wegrzynowicz, CIA, internal audit director at Lafarge SA, and Steve Stein,
CIA, global IT audit manager at Hewlett-Packard, for contributing a great deal of time and effort to the project.
I encourage you to use this authoritative guidance to build your working knowledge on IT-related project
management, for it surely will contribute to the success of your organization’s future IT efforts.

Sincerely,

Richard F. Chambers, CIA

IIA President
Global Headquarters

1
GTAG — E
 xecutive Summary

1. Executive Summary how the internal audit function can participate actively in
the review of projects while maintaining its independence.
Organizations invest large amounts of capital to fund the imple- The IIA’s International Standards for the Professional Practice
mentation of new information systems, enter new markets, of Internal Auditing provide principle-focused guidance for
develop new products, and manage alliances and acquisitions. performing these engagements.
Project teams are often created to manage such efforts. These Within the context of this GTAG we have chosen to
investments don’t just bring about positive change to the focus on five key components of IT projects for which we
organization, but also present a high degree of risk. As a result, recommend building an audit approach (see Figure 1):
the success or failure of these investments can be critical to the 1. Business and IT Alignment
strategy of an organization, as well as have an impact on the 2. Project Management
organization’s efficiency and reputation. 3. IT Solution Readiness
Many projects and investments are focused around infor- 4. Organizational and Process Change Management
mation technology (IT). In the past, studies such as “The 5. Post Implementation
CHAOS Report,” conducted by The Standish Group, indi-
cate that for IT projects in particular, the failure rate can be Figure 1 shows that project management is the central
as high as 50 percent1. Project failure often comes down to concept that links all of these areas. When planning the
two key things: too much optimism from a people aspect, project audit approach, the auditor should consider all five
or technology failures from a systems perspective. Given the of these areas to ensure that all major risks are addressed.
level of risk that projects face, it is essential for the internal This guide is not intended to be a complete project risk
audit department to be aware of the projects taking place in assessment or audit guidance; rather it provides an outline of
the organization and to determine at what stage it should be key considerations for auditing IT projects. Auditing projects
involved in order to provide guidance on the controls aspect is an excellent opportunity for internal auditing to provide
of the project or an independent assessment of the achieve- assurance on strategic risk. A number of studies have shown
ment of desired results. that internal auditing spends a large amount of time auditing
Internal auditing can contribute to the success of IT proj- operational risk, but not enough on strategic risk. Project
ects by assessing project-related risks. Auditors can focus on audits can provide an opportunity to expand the risk focus.
areas such as security and internal controls, and they can
play a role in evaluating the overall project management.
Business
By helping project teams respond to risks, internal auditing & IT
can increase the project’s chance of success. As discussed in Alignment
GTAG 8: Auditing Application Controls, internal auditing can
add value through both traditional assurance and consulta-
tive engagements.2
In a 2002 Internal Auditor article, Richard B. Lanza wrote:
“To be successful , auditors must demonstrate to both senior Post Project IT Solution
Implementation Management Readiness
management and project managers the value that an inde-
pendent advisor can bring. Senior management can give
auditors access to projects, but auditors can be more effective
when the project managers buy into their involvement and
give them greater access.”3
The purpose of this GTAG is to provide the chief audit Organizational
Change
executive (CAE) and internal auditors with an overview Management
of techniques for effectively engaging with project teams
and project management offices (PMOs) to assess the risks
related to IT projects. The field of project management is Figure 1: Five Key Focus Areas for Auditors
quite broad, and as such the purpose of this guide is to outline
a framework for assessing project-related risks, provide
examples of common project management risks, and discuss

The CHAOS Report 2007, The 10 Laws of CHAOS, The Standish

1  

Group, 2007.
2  
GTAG 8: Auditing Application Controls, p. 5.
“Technology Projects: The Riskiest Parts of the Business.” Internal
3  

Auditor, May 15, 2002, Richard B. Lanza, CPA, PMP.

2
 GTAG — Introduction

2. Introduction is no shortage of ideas, articles, and white papers on the

subject. Regardless of the interpretation of the data, there is
2.1 What Exactly Is an IT Project? overwhelming evidence that projects pose a significant chal-
The term IT Project is a bit of a misnomer. In reality, most lenge. Ultimately, management is accountable for ensuring
system implementation or maintenance projects are increas- that the project and benefit outcomes are achieved.
ingly complex initiatives that involve or impact more than
just the IT department and, as such, should be considered
as a business project as well as an IT project. In the most 2.3 Examples of Failed IT Projects
general sense, a project is a unique set of activities with a Most large IT project failures will never be publicized
discreet beginning and end, undertaken to achieve a partic- because of the negative impact the disclosure would have on
ular purpose within defined constraints of schedule, scope, an organization’s reputation and shareholders. However, the
and resources. It is important to note that this GTAG is following are some examples of significant failures that have
intended to focus on projects that include a technology- been reported.
related solution; however the principles are very similar to • In August 2005, CIO Magazine reported that a large
other types of projects. U.S. government agency had to scrap a US $170
IT-related investments have been a major source of expen- million virtual case file management system develop-
diture for organizations for many years. They tend to come ment project due to schedule delays, cost overruns,
in waves, and all organizations worldwide respond to them. and technical difficulties.4
Large IT projects easily can cost tens of millions of dollars. • In 2004, one of the top telecommunications compa-
Major waves of IT system-related projects in the last 15 years nies in the world experienced a project failure during
include enterprise resource planning (ERP) systems, solving a CRM system upgrade. The resulting problems
the Year 2000 problem, e-commerce/dot-com solutions, and cascaded across the IT environment and led to disrup-
customer relationship management (CRM) systems. Such tions in wireless service to customers. The company
projects could include building new infrastructure, new lost many customers over the incident, and the
product development (commonly referred to as research and revenue impact was estimated to be US $100 million.
development, or R&D), and the implementation of new The stock price fell and before it could recover, the
business processes or business transformations. In the evalu- company was sold to a competitor for less than half of
ation of such projects, it is necessary to understand the key the original share price.5
risks, and to develop a set of criteria to evaluate the project • In 1999, one of the largest food manufacturers in
at various stages. the world suffered a significant ERP implementation
failure, which resulted in two profit warnings in the
last quarter of the year. The event led to significant
2.2 Understanding the Impact product distribution problems during the critical
Today, determination of a project’s success extends beyond holiday sales season. By year end, the stock price was
traditional on-time, on-budget metrics. Failed or challenged down 27 percent, which was very poor considering a
projects can have a significant impact on an organization, stock market boom was occurring at the time.6
depending on the business need behind the project. A few
examples of possible risks include:
• Disruption of service to customers. 2.4 Historical Statistics on IT
• Loss of competitive advantage. Project Success and Failure
• Fines from failed regulatory compliance. Statistics around IT project failures have been studied consis-
• Loss of revenue. tently and reported over the last two decades by numerous
• Negative impact on reputation. analysts and consultants, including the Gartner Group,
• Delays in deploying critical strategic initiatives, Forrester Group, The Standish Group, and KPMG. There
products, or processes. are far too many reports and statistics to discuss here, but
• Loss of expected return-on-investment.
• Loss of critical business and IT personnel.
“Why the G Men Aren’t IT Men,” Allan Holmes, CIO Magazine
4  
• Facility closure or damage.
Online, Aug. 15, 2005.
• Loss of shareholders/investors.
20 Questions Directors Should Ask About IT Projects, 2007.
5,6  

Adapted with permission from the Canadian Institute of Chartered

Many researchers and consulting firms have performed
Accountants, Toronto, Canada. Any changes to the original material
studies reporting on the fact that IT projects are regularly are the sole responsibility of the publisher and have not been reviewed or
challenged or fail — they are over budget, behind schedule, endorsed by the CICA.
do not achieve objectives, or are cancelled. As a result, there

3
GTAG — I ntroduction

the CAE should be aware of the research to understand the typical company runs 29 projects at any one time and
inherent risks associated with IT projects. Auditors should has an average IT budget of between £1m and £5m8
investigate statistics and failures that relate to their specific (US $1.4m and US $7.03m).
organization and industry. Such statistics can be presented to • KPMG’s Global IT Project Management Survey,
management when discussing the need for project audits. The released in 2005, found that 49 percent of survey
following are some examples of relevant research regarding participants had experienced at least one project
project failures. failure in the previous 12 months. Further, the report
revealed that 59 percent of organizations either have
• The 2007 CHAOS Report from The Standish Group7 no process or only an informal process in place to
provides summary results of its research studies from assess whether or not a project is on track to provide
1998 to 2006. The data shows that project success the intended benefit.9
cannot be taken for granted. As of 2006, 65 percent
of projects either failed or were challenged, meaning These are just a few examples. While it is possible to debate
that they were unable to meet all or part of their the detailed accuracy of such statistics, the fact remains that the
objectives, cost, or schedule goals. large number of project failures has been reported consistently.


 2.5 Top 10 Factors for Project Success

To counter the failures many research groups provide ideas
 on steps to take to ensure that projects have the best chance
for success. The Standish Group provides an annual report

based on its research of why projects succeed. The following
 10 rules for success come from the latest Standish annual
project management report, “The CHAOS Report 2007.”10

1. User Involvement – Business and IT users are involved
 with key consensus-building, decision-making, and
1998 2000 2002 2004 2006
information-gathering processes.
■ Succeeded ■ Failed ■ Challenged 2. Executive Support – Key executives provide alignment
with business strategy, as well as financial, emotional,
1998 2000 2002 2004 2006 and conflict resolution support.
3. Clear Business Objectives – Stakeholders understand
Succeeded 26% 28% 34% 29% 35% the core value of the project and how it aligns with
business strategy.
Failed 28% 23% 15% 18% 19% 4. Agile Optimization – Project uses iterative develop-
ment and optimization processes to avoid unnecessary
Challenged 46% 49% 51% 53% 46%
features and ensure critical features are included.
5. Emotional Maturity – Project manager directs the
Table 1. CHAOS Research Study
emotions and actions of project stakeholders and
avoids ambition, arrogance, ignorance, abstinence, and
• CA, Inc. sponsored an independent research group fraudulence.
in the United Kingdom, Loudhouse, to survey 100
IT directors across the UK and Ireland. The study Over Budget IT Projects Cost UK Plc £256m Per Year, CA Inc.,
8  

concluded that poor visibility into IT project status Sept. 12, 2007.
and a lack of management control over projects is Global IT Project Management Survey. © 2005 KPMG
9  

costing UK companies a quarter of a billion pounds International. KPMG International is a Swiss cooperative that
(US $350 million) each year. A third of all projects serves as a coordinating entity for a network of independent firms
implemented each year end up over budget, with the operating under the KPMG name. KPMG International provides
typical over-spend between 10 percent and 20 percent no services to clients. Each member firm of KPMG International
of the original budget. The survey also highlighted is a legally distinct and separate entity and each describes itself as
such. All rights reserved. Printed in Hong Kong. KPMG and the
the increased complexity of IT projects; it indicated a
KPMG logo are registered trademarks of KPMG International, a
Swiss cooperative. August 2005.
The CHAOS Report 2007, The 10 Laws of CHAOS, The Standish
7  
The CHAOS Report 2007, The 10 Laws of CHAOS, The
10  

Group, 2007. Standish Group, 2007.

4
 GTAG — Introduction

6. Project Management Expertise – Organization uses

project managers who understand the basic skills
and practices, such as certified Project Management
Professional from the Project Management Institute
(PMI) or the like.
7. Financial Management – Project manager is able to
manage financial resources, account for project budget/
costs, and demonstrate the value of the project.
8. Skilled Resources – Skilled project personnel are
acquired, managed, retained, and controlled to move
forward in the face of turnover and other personnel
hurdles.
9. Formal Methodology – There is a predefined set of
process-based techniques that provide a road map on
when, how, and what events should occur in what
order.
10. Tools and Infrastructure – The project infrastructure
is built and managed with tools that enable manage-
ment of tasks, resources, requirements, change, risks,
vendors, user acceptance, and quality management.

2.6 Purpose and Benefits of

Internal Audit Involvement
While all of the success factors outlined above are clearly the
role of management, internal auditing can add considerable
value by evaluating the effectiveness of risk management
over both the IT and organizational aspects of IT-related
projects. Internal auditing offers an independent approach
to assessing whether an organization or function is achieving
its stated objectives. Auditors analyze business processes or
activities in a methodical way to highlight issues and recom-
mend corrective actions. Given the IT-related project risks
outlined above, internal auditing can bring the value of their
experience and methodology to review projects in the early
stages to also help increase the likelihood of success. Benefits
of internal audit involvement may include:
• Providing independent ongoing advice throughout
the project.
• Identifying key risks or issues early, which enables
project teams to operate proactively to mitigate risks.

5
GTAG — Five Key Focus Areas for Project Audits

3. Five Key Focus Areas the business case. Therefore, for the purposes of this GTAG,
for Project Audits we will focus on just a few of the common risk areas.
Key components of the business case should include:
• Benefits that are realistic, understood, and
Research has shown not only what some of the risks are, measurable.
but also that early intervention is a key to success. As stated • Environmental concerns such as the regulatory land-
in the introduction, this GTAG focuses on five key areas scape, architectural compatibility, etc.
of projects around which we recommend building an audit • Organizational considerations such as who should be
approach. The following five categories were chosen as the involved from what functions.
logical areas around which to focus based on a variety of • A clearly defined project scope.
research and the authors’ past experience with using various • Project deliverables, in terms or process and
project risk assessment methodologies. functionality.
1. Business and IT Alignment • Necessary resources, both in terms of cost and
2. Project Management people.
3. IT Solution Readiness • Analysis of the risks regarding the viability of part-
4. Organizational and Process Change Management ners or vendors.
5. Post Implementation • Measurement or likelihood of success.

The next sections provide considerations for each of the In building the business case, it is essential to establish
five key focus areas. (See Appendix F for a suggested list of project sponsorship as well as project impact. At the earliest
audit questions and examples of specific risks and controls for phase, project sponsors must understand the full impact of
each of these focus areas.) the project and to ensure all internal and external stake-
holders are considered. The direct stakeholders include
internal departments or functions that will use the new
3.1 Business and IT Alignment system, external customers or suppliers who may interact
Alignment simply means that the vision and objectives of with it, and anyone else with a vested interest. It is important
both the business and IT are understood, are in harmony also to ensure that indirect stakeholders are consulted early,
with each other, and that the project is in line with the which could include finance, internal audit, IT security,
strategy of the organization. Almost every project consists legal, purchasing, or regulatory functions. Feedback should
of interdependence among various levels and functions of an be received from all impacted groups — even those on which
organization. This means that achieving and maintaining the impact may be minimal — to ensure all considerations
alignment is a significant challenge throughout the life of are taken into account.
the project! Regular meetings with all stakeholders present The business case should ensure that all available alter-
and channels for an open flow of communication are critical, natives are considered. Typical factors include building
as are fully dedicated sponsors who provide the leadership, the solution in-house or buying an external package; using
time, and energy that the project requires. Further to the internal resources versus outsourcing; and of course consid-
sponsorship, the project team selection is equally crucial. A ering whether the project is in response to a regulatory
project team that is lacking the right experience, skill set, requirement, or simply a business efficiency solution. In
and willingness to support the project is a prevalent barrier the analysis of alternatives, a strong business case enables
to project success. There are many aspects associated with management to make the most informed decision and to
project alignment, and for many organizations these aspects understand the trade-offs that must be considered. Lastly, the
are incorporated into the business case. business case should assess the capacity of the organization to
undertake the project, the priority level of the project, and
whether the organization has the people with the right skill
Assessing the Business Case set to execute it.
For any project to get started, management needs informa-
tion to determine the viability of taking what sounds like
a good idea forward. Preparation of the business case is a 3.2 Project Management
process that is followed by a dedicated team to provide
the information necessary to facilitate a decision regarding Understanding Project Management
whether to proceed with the project. The ultimate decision As depicted in Figure 1, project management is central to the
may be taken by the project steering committee, or may be five focus areas. Project management, like internal auditing,
taken at a higher level in the organization. Indeed, entire is a profession with its own set of best practices, terminology,
audit guides have been written on the subject of reviewing and standards. (Due to the wide availability and broad

6
 GTAG — Five Key Focus Areas for Project Audits

scope of guidance on project management as a profession, For instance, large defense contractors may use a complex
the appendices of this GTAG were developed to provide methodology such as earned value management (EVM) — a
a summary of project management reference material, best project management technique for measuring project prog-
practices, and standards.) Auditors should be careful to ress in an objective way by combining scope, schedule, and
ensure they fully understand the risks associated with project cost12  — in order to support large government contracts,
management. Even an auditor with a strong IT and business while a small organization may use a simple project manage-
background may find many project management best prac- ment software package or spreadsheet just to track the project
tices unfamiliar. Internal auditors will have to invest time to tasks and status.
study and better understand project management processes Before performing any project audits, the CAE and the
and terminology. internal audit team should first gain an understanding of
The following terminology is fundamental to project the organization’s project management methodology — also
management: known as an ecosystem or life cycle. Additionally, they must
• Project Portfolio ­– The collection of projects within understand the best practices, risks, and controls associated
an organization. Programs may include a number with both project management and systems development.
of projects. In order to plan, scope, and assess proj- Failure to understand this relationship could result in an
ects and programs, the auditors must understand internal auditor not scoping IT project audits to account for
the concepts of project management, project gover- the full range of possible risks.
nance, and project management methodology within Figure 2 shows the components that might be included in
the context of their business and organization. a methodology and where key controls should reside. It also
• Project Management – The discipline of organizing highlights the interdependence between levels and func-
and managing resources (e.g. people and budget) so tions that exist, and to what level the audit may need to
that the project is completed within defined scope, go to have a complete understanding of the project magni-
quality, time, and cost constraints. tude. The organization’s project management methodology
• Project Governance – The overlap between proj- provides the context the auditor needs to perform the audit.
ects and corporate governance, the governance of The methodology offers a basis for helping the auditor during
project management at the entity level. It ensures the the planning and execution of audits to identify key project
organization undertakes the right projects, controls governance groups and key project management control
the project portfolio, establishes priorities, assigns points, and to determine the policies, standards, and best
authority to the correct level, and has appropriate practices against which to audit.
decision-making processes in place. Good project Table 2, Project Methodology Components and Value to
management governance ties all of the areas illus- Auditor, highlights the major methodology components and
trated in Figure 2 (on page 8) together and ensures their value to the auditor.
that they have the support to operate effectively.
• Project Management Methodologies – Broad collec-
tions of integrated policies, standards, methodologies,
life cycles, procedures, tools, techniques, stakeholders,
and organizations that are used to guide the plan-
ning and execution of a project. The Standish Group
points out that the methodology also includes what
it calls “the other 90 percent of a project environ-
ment” (e.g., emotional attitudes, culture, stakeholder
education, and nonprocess/procedure maturity of the
organization).11

Auditors and Project Management

Methodologies
Just like it is true that no two businesses are the same, it is
also true that no two project management methodologies are
the same. Every organization will use a different combina-
tion of methodologies, life cycles, best practices, tools, etc.

CHAOS Chronicles Online, v14.2.1, Glossary Definition of

11  
Practice Standard for Earned Value Management, Project
12  

Ecosystem, The Standish Group, 2008. Management Institute, March 2005.

7
GTAG — Five Key Focus Areas for Project Audits

BUSINESS STRATEGY/PROCESSES/ACTIVITIES

Supply-
R&D Payroll HR Sales Design Manufacturing Financial Chain IT

Etc.

Align
Business
& IT IT PROJECTS

New Systems/Apps Infrastructure Upgrade Innovation

Etc.

PROJECT MANAGEMENT METHODOLOGY

Project Management Office Stakeholders PM Culture

PROJECT MANAGEMENT PRACTICES

PM Best Practices, Policies, and Processes
PM
Controls

SYSTEMS DEVELOPMENT LIFECYCLES IT Controls

• Systems
Development
Rapid App. Waterfall Etc. • Logical Access
• Interfaces
• Data Migration
Etc.

Figure 2. Project Management Methodology. Adapted and revised from IT Control Objectives for Sarbanes-Oxley, Second
Edition, used with permission of the IT Governance Institute (ITGI) © 2006 ITGI. All rights reserved.

8
 GTAG — Five Key Focus Areas for Project Audits

Methodology
Value to Auditors Examples
Component
Organizational

Project Stakeholders Provide auditors with multiple perspectives (busi- • Business Owner
ness, IT, contractor, etc.) on the risks and issues • IT Owner
associated with individual projects.

Project Management Provide a centralized location to identify and review • Strategic/Global

Offices all project methodologies and associated deliverable • Single Project
requirements, which aids in annual audit planning • Business Unit
and scoping, audit program development, etc.
Models and Methods

Project Portfolio Provides a centralized location to identify and review • Strategic/Global

Management all projects, which aids in annual audit planning, • Single Project
audit prioritization, etc.

Project Management Provides a “measuring stick” for planning project • T he Portfolio, Program, and
Maturity Models audits. Auditors can assess project methodologies and Project Management Maturity
processes to identify gaps as a basis for improvement. Model (P3M3)
• Organizational Project
Management Maturity Model
(OPM3)

System Development Provides a “measuring stick” for scoping and plan- • C apability Maturity Model
Maturity Models ning project audits. Auditors can assess project Integration for Development
methodologies and processes to identify gaps for (CMMI)
improvement. • The Software Process
Improvement and Capability
dEtermination (SPICE)

Software Development Provides a basis for identifying and assessing adher- • Waterfall
Life Cycle (SDLC) ence to system development processes, as well as • Rapid Application
when to use or not use a particular approach. Development (RAD)

Project Management Provides a foundation for developing an audit • P roject Management Body of
Best Practice Guides approach and a basis for assessing organizational and Knowledge (PMBOK)
project-level performance. • Projects in Controlled
Environments (PRINCE2)

Automated Tools Enables review of audit schedules, expenditures, • Schedule Management

resource allocation, issues, etc. If portfolio manage- • Resource Management
ment tools are used, they enable the auditor to run • Issue Tracking
reports listing all projects in order to risk-prioritize
projects based on budgets and schedules, and to use
metrics to identify “troubled projects.”

Table 2. Project Methodology Components and Value to Auditor

9
GTAG — F
 ive Key Focus Areas for Project Audits

Project Stakeholders Project Portfolio Management

Internal auditors must understand how their organiza- Project portfolio management (PPM) refers to the collective
tion identifies and includes stakeholders in IT projects. management of projects to ensure that well-informed project
Stakeholders are the collection of people and groups that investment decisions are made. Organizations use PPM to
make the project happen. Projects simply cannot succeed make better IT investment decisions, ensure adequate funding
without the proper stakeholders working together in a across business requirements, and elevate the role of IT in the
well-coordinated way. Executive stakeholders must provide organization by showing the value of all IT initiatives and
strategic guidance, as well as financial, political, and projects. Internal auditors can use PPM to identify high-risk
emotional support. Business and IT user stakeholders ensure projects and the overall priorities of the organization.
that the requirements and final product meet the intended
business need. The number and types of stakeholders vary
by organization and project. (See Appendix B for a list of Internal Auditors and Maturity Models
typical stakeholders.) Generally speaking, maturity models exist to help organi-
zations move from less mature processes to more mature
processes. They help the organization identify current weak-
Project Management Office (PMO) nesses and gaps in capability and identify its current level of
and the Internal Auditor maturity and then plot a strategy for improving to the next
If the organization has a PMO, this will be a key starting level of maturity. The general idea is to develop well defined,
point for the internal auditor to understand the organiza- robust, and repeatable processes. There are specific maturity
tion’s project management culture, methodologies, standards, models for software development and project management.
and processes. Many organizations implement PMOs to help (See Appendix D for a summary of maturity models.)
govern and influence project success across an organization. Auditors can use maturity models as a basis for assessing
According to studies by the Project Management Institute, an organization’s project management and/or systems devel-
the top reasons for implementing a PMO are to improve opment processes. However, this probably only makes sense
project success rates, standardize practices, and lower costs. if the organization has already chosen a maturity model and
Although small organizations can manage projects effectively is structuring its processes to be aligned with a model. If an
without a PMO, large organizations with a vast number of organization plans to implement a maturity model for the first
projects will find success unlikely without one. time, internal auditing could perform an initial audit against
Because of the critical role the PMO can play in a project the proposed maturity standard. This would provide a base-
management methodology, it is essential that the auditor line understanding for the organization to begin its use of the
develops and maintains a strong relationship with the PMO. maturity model.
PMOs may play a key role during project audits and may Auditors should view the use of maturity models by the
serve as a valuable liaison between internal auditing and organization as a very positive step in terms of improving the
project managers. Auditors can play an advisory role to the organization’s IT project management approach. However,
PMO by sharing their perspective on IT project risk and by there is no requirement for an organization to use a maturity
setting auditing’s expectations for the PMO and individual model, and many do not because of the cost and complexity.
projects. IT project auditors should seek to understand the
following:
• PMO’s roles and functions Best Practices for IT Project Management
• Project management methodologies Best practices provide an ideal starting point for auditors to
• IT project cost and schedule performance data and frame their risk assessment and audit approach. Best prac-
trends tices come from both general project management guides
• IT project success/failure rates, statistics, metrics, and as well as those that are specific to IT development. Some
lessons learned widely accepted examples include:
• Trends that are driving success or failure across all IT • Project Management Body of Knowledge
projects (PMBOK).13
• PRojects IN Controlled Environments
They should also seek to obtain a listing of approved and (PRINCE2).14
funded IT projects annually — sorted by budget, risk, or
other key factors — and a listing of major milestones and
go-live dates for major system implementations.
Project Management Body of Knowledge (PMBOK), Project
13  

Management Institute, 2008.

PRojects IN Controlled Environments (PRINCE2), United
14  

Kingdom’s Office of Government Commerce (OGC), 2008.

10
 GTAG — Five Key Focus Areas for Project Audits

• Control Objectives for Information and related Systems Development

Technology (COBIT).15 oo Software defect tracking
• International Standards Organization (ISO) oo Software testing
Standards.16 oo Source code management and version control

Internal auditors should not expect organizations to fully

implement PMBOK, PRINCE2, COBIT, or any other large 3.3 IT Solution Readiness
set of best practices. Rather, they should expect to see that IT solutions have a natural development life cycle that
these practices have been customized and integrated into the includes a sequence of phases that must be followed in
organization’s project management methodology. Appendix order to convert a management need into an IT system or
E - General Project Management Best Practices gives more application and to maintain the system in a controlled way.
details on each of these best practices and frameworks. Typically, this sequence is referred to as a software life cycle
(SLC) or software development life cycle (SDLC). (See
Figure 3: Generic Software Development Life Cycle.)
Project Management Tools and Automation Organizations may use their own software life cycle
Auditors should expect to see any number of automated tools methodology for custom development or one provided by
for project management or teamwork being used on projects. consultants or vendors for use with their products. SDLCs
Software may by used to manage entire portfolios containing may vary by the type of technology being developed. They
hundreds of projects, and/or individual projects. Auditors may be customized to meet any of the following development
may leverage these tools to obtain: or implementation scenarios:
• Information on cost, schedule, and technical • Custom development using internal resources
problems. • Custom development using fully or partly outsourced
• Insight into project decision-making and issue- resources located on site or offsite (locally or in an
tracking. offshore location)
• Information on resource utilization. • Vendor software packages implemented as-is with no
customization
The following are some examples of project areas that may • Vendor software packages customized to meet specific
benefit from automation and tools. requirements
Well-known types of SDLC models include Waterfall and
Project Management Rapid Application Development.
oo Schedule management Regardless, the internal auditors should expect to see some
oo Cost management type of development life cycle and will need to determine
oo Requirements management whether it is appropriately followed. They’ll then use the
oo Issue tracking phases in the life cycle to determine when to perform the
oo Resource management project audit and what controls to test.
oo Risk management The implementation phase of the project is often thought
oo Quality management of as simply when the new system gets “turned on” in produc-
oo Team collaboration/knowledge sharing tion; however, there are a series of critical steps and decisions
that take place during the course of the project. Many project
failures have been attributed to a lack of interim check-
Control Objectives for Information and related Technology
15  
points, which should be established as part of the project
(COBIT), IT Governance Institute, 2008.
16  
International Standards Organization (ISO) Standards, ISO, 2008.

Software Development Life Cycle

Requirements Design Build/Code Test Implement Maintain

Figure 3. Generic Software Development Life Cycle

11
GTAG — F
 ive Key Focus Areas for Project Audits

management methodology with the specific goal of the is duplicate or old data in the old system, the data should be
project team making a conscious decision to move forward cleansed before doing a conversion whenever possible.
with the project. Projects that are especially complex, such
as an enterprise resource planning (ERP) system, should
include specific decision points at the end of significant Testing and Go-live
project milestones to ensure the project is on track. The next key step is the testing phase. It is essential to
determine whether testing includes not only the end users,
but also the workflows, security, and connectivity to other
External Consultant Assessment systems. Once testing is complete, there should be a check-
During the solution or system implementation phase of the point to decide on the readiness for go-live, or the launch
project it is quite common for the project management team in production. The go-live should not merely be considered
to partner with an external firm or resource, especially for the as an event, but rather a phase in which a transition plan is
implementation of a large package such as an ERP. Auditors in place to transition the new system from the project team
should consider whether the viability of the external partner to the team that ultimately will be responsible for ongoing
chosen has been reviewed especially for a project that will operation and support. In this phase it is important for the
be lengthy. In addition, it is essential that the roles and project to take into account contingency or fall-back strate-
responsibilities of all parties are well defined up front so that gies to mitigate any unforeseen issues that arise with the final
everyone will have a clear understanding of where account- implementation. During this phase of the project there is
ability lies for the deliverables of the project. usually significant pressure to show progress and meet dead-
lines and, as a result, some important aspects of the detail
planning may be overlooked.
Solution Design
During the solution design phase of the project, auditors
should look to ensure that business requirements and both 3.4 Organizational and Process
the existing and future business processes are taken into Change Management
consideration. At the end of this phase, the project scope For any project, organizational and process change manage-
should be frozen, and all functionality should be prioritized ment is often the most important element to manage and,
in terms of what is required for the system launch. This in fact, can present the most risk to a project. The most
prioritization is often referred to as the “must-have versus complex scenarios include both the change of a business
nice-to-have” decision. It’s also typical during this phase for process and the related information systems. Good project
the project team to decide whether to build the solution in management governance processes, as illustrated in Figure 2,
house or to buy an external package. Regardless of the deci- enable effective change management. Change management
sion made, it is imperative to ensure that both functional encompasses more of the soft, or intangible, aspects of a
and security-related internal controls are considered so that project, including understanding the magnitude of how the
they will be included in the solution up front. project will impact the organization and how it will change
the way people work. From an audit perspective, this is where
the integrated audit team becomes essential to ensure opera-
Code, Build, and Data tional and technical aspects are assessed, with the right level
Following the design phase, there should be a process to of skills from the audit team.
review the actual coding or building of the system. Within a
system’s life cycle, there may be many different internal rules
or guidelines that the audit can follow. For example, a code Managing Communication
development process review can be performed to determine One of the most critical aspects of change management
whether robust and secure programming methods are being is managing communication in a broad sense, beginning
followed. Following the system build, the configurations or with obtaining buy-in and representation from all stake-
localizations will take place, followed by the conversion and/ holders, marketing the benefits or reasons for the project,
or loading of new or legacy data. In addition, the interfaces and managing the expectations of end users. For example,
or connectivity to other systems in the organization will be what processes will be impacted by the new system and what
set up. The data loading consideration is one of the most impact will the changes have on vendors or customers? These
critical, in particular the preparation of any master data such points should be stated clearly at the beginning of the project
as employee, customer, or vendor files. While it is important and must be managed well beyond post implementation.
to ensure that there can be continuity of legacy information,
it is imperative to start with data that has been clearly identi-
fied prior to loading to the new system. In other words, if there

12
 GTAG — Five Key Focus Areas for Project Audits

Organizational Readiness A post implementation review can take a couple of

Organizational readiness entails assessing changes to the different approaches. More detailed information on
organization proposed by the new project and managing conducting a post-implementation review can be found in
the level of resistance there will be to the change. This is Section 4.3, on page 16.
especially true with projects that involve centralization of
processing, such as a shared service center combined with
the implementation of an ERP, or with those involving
outsourcing. An assessment should be made on the skill set
of existing staff members compared to changing or new roles,
and determine whether processes or workflows are clearly
defined, to gauge the readiness of the organization to accept
the change.

Training
A key success factor for any new system implementation
is ensuring that all users who will be impacted receive
adequate training. The audit team should evaluate whether
the training is complete, timely, and includes user guides
that are not generic. In addition, training provided to the IT
team and/or helpdesk personnel should be reviewed to deter-
mine whether it is adequate to support the new system.

Postlaunch Support
It is essential for auditors to ensure that a post go-live support
plan is defined in terms of the support team organization,
for both functional and technical issues. The support team
should be analyzed to determine whether it is correctly sized
for the go-live and postlaunch workload, which is usually
much higher than normal. Additionally, contingency plans
should be established in the event something goes wrong
during the go-live period.

3.5 Post Implementation

Following the system go-live, there inevitably is a stabi-
lization period. During this time, the users are getting
acclimated to the system or new functionality, and any
outstanding issues are being resolved. During this phase,
there are key risks to watch for — many of which are
related to change management aspects. In other words,
the auditors must determine whether the new system is
being used correctly and the functionality is meeting the
requirements as intended. If many changes were made to
the business processes along with the implementation of
a new system, the stabilization period can take a rela-
tively long time. A key consideration is to determine
whether there is any prolonged resistance to change.
For example, are users finding a work-around or short
cuts because the new system is not as user-friendly as its
predecessor? Discussions and interviews with users can be
held to determine this.

13
GTAG — P
 roject Audit Planning

4. Project Audit Planning entire list of IT or technology-related projects. Ideally, there

should be a list of all projects in a centralized system where
IT projects should be included in the annual internal audit auditors can run reports based on risk factors such as the cost
plan using a systematic process. Figure 4: IT Project Planning of the project, schedule, project risk, project duration, etc.
Process depicts a logical workflow progression that uses a If no such list exists, questions regarding IT or technology-
top-down approach to determine which projects to audit. It related projects can be raised during annual audit planning
is consistent with the large audit planning process described to both IT and key business functions. In addition, the PMO
in GTAG 11: Developing the IT Audit Plan.17 can be an invaluable source of information to aid auditors as
Internal auditors can add considerable value by evaluating they develop the audit universe and the annual audit plan,
both the IT and organizational aspects of IT-related projects. and as they plan audits of individual projects. The internal
Key questions the internal auditor should consider include: auditors should engage with the PMO as part of scoping and
• How should IT project audits be incorporated into planning prior to conducting IT project audits.
the annual audit plan? The following points may be useful for auditors to consider
• What is the appropriate role for the internal auditor? when assessing the project risk at the organizational level
• What projects should be audited and why? and to determine how to include IT-related projects in the
• What type of project audit should the internal auditor annual audit plan:
perform? • A complete and accurate inventory of all projects —
with enough supporting information to assess the risk
at a high level — is unavailable.
4.1 IT Projects and the Annual • There are a large number of IT projects spread across
Internal Audit Plan the company.
To include projects in the annual audit plan or audit universe, • The organization lacks centralized methodologies and
internal auditing should have access to the organization’s processes for project governance, including project
management methodologies and system develop-
ment life cycles.
17  
GTAG 11: Developing the IT Audit Plan, pg. 3.

Understand
Project Define IT Formalize
Perform Risk
Management Project Project
Assessment
Approach and Universe Audit Plan
Auditing’s Role
•• Determine whether •• Identify all the IT project •• Develop processes •• Determine which projects
auditing should take in the organization. to identify risks. to audit based on risk.
an assurance or •• Ensure that the projects •• Assess risk and •• Determine the
consultative role. lists are complete rank projects using appropriate type
•• Get buy-in from and current. IT risk factors. of project audit to
senior management •• Assess risk and perform (e.g. solution
on internal auditing’s rank projects using readiness, etc.).
role in projects. business risk factors. •• Determine timing
•• Determine how IT •• Consider the five key to get maximum
projects are being risk areas identified benefit (e.g. pre-
used to implement the in this GTAG. implementation, etc.).
organization’s strategy.
•• Understand the key
groups in project
governance (e.g. PMOs,
review boards, etc.).
•• Understand the
project management
methodology,
deliverables, phases, etc.

Figure 4. IT Project Planning Process, adapted from GTAG 11: Developing the IT Audit Plan.

14
 GTAG — Project Audit Planning

• Senior management is overly confident in its ability As an additional resource, the IT auditor may also consider
to deliver projects effectively, yet cannot produce Information Systems Audit and Control Association’s
evidence of project inventories or centralized (ISACA’s) Guideline G17: Effect of Non-audit Roles on the
methods. IS Auditor’s Independence.18
• Project managers and senior management believe The sooner the auditor engages with a project, the better.
that auditors cannot add value to projects and that Internal audits or assessments performed during the early
project teams are too busy to deal with supporting a phases of the project can be the most valuable because they
project audit because of lack of resources, impending can identify issues earlier and reduce cost. When auditors
deadlines, etc. find issues, their recommendation often includes the addi-
tion of automated controls or possibly design changes. It has
been well established in studies of software development that
4.2 Internal Auditing’s Role software fixes and adjustments are far cheaper to address in
When considering the internal auditor’s role, a key point to the early project stages, such as the design phase, rather than
keep in mind is the nature of the internal audit organiza- in the later stages of the project. Finding and fixing a soft-
tion and whether the function is mandated to perform only ware problem after delivery is often 100 times more expensive
assurance type engagements, or whether engagements that than finding and fixing it during the requirements or design
are more of an operational or consultative nature are also phases.19 Figure 5: Relative Costs to Fix Errors Throughout
permitted. The IIA’s International Standards for the Professional Life Cycle shows the dramatic relative cost of fixing software
Practice of Internal Auditing provide the necessary guidance changes throughout the life of a project. This can be a major
for the internal audit function to perform these roles. selling point in convincing senior management to support
Internal auditors can add significant value to a project by early internal audit involvement in the project.
engaging early and supporting the project team throughout
the project life cycle. They may be asked to support the project
in various capacities, ranging from consultative reviews to
formal audits. This can create the potential for perceived IS Auditing Guideline G17: Effect of Non-audit Roles on the IS
18  

impairment of auditor independence. The IT auditor should Auditor’s Independence, Information Systems Audit and Control
provide reasonable assurance that his or her interest, if any, Association, 2003.
in the IT solution will not impair the objectivity of the Reproduced by permission from Steven Rakitin, Software
19  

review, and that his or her participation is one of providing Verification and Validation: A Practitioner’s Guide, Norwood, MA:
advice without being responsible for making the decision. Artech House Inc., 2001. © 2001 Artech House Inc.

Relative Cost to Fix Errors Throughout Life-Cycle

120 $100

100
Cost to Fix ($)

80

60
$50
40

20 $20

0 $1 $5

nts sig
n de st nce
me Co Te na
e De te
q uir ain
Re Phase when error is found and fixed
M

Figure 5. Relative Costs to Fix Errors Throughout Life Cycle. Adapted from Software Verification and Validation for
Practitioners and Managers, Second Edition19

15
GTAG — P
 roject Audit Planning

4.3 Types of Project Audits project methodology or SDLC, or to measure how well the
Internal auditors may perform a variety of different reviews, new system is working. A post-implementation review likely
depending on the project risk and needs of the organization. would use an integrated audit approach because both the
This GTAG highlights five of the most common types of system and related business processes should be examined in
project-related audits or assessments to consider: tandem.
• Project risk assessment to gauge likelihood of success. During the project initiation and development of the
• Readiness assessment during key phases or pre-launch. business case, many project benefits are noted. A benefits
• Post implementation review. realization review is another type of post-implementation
• Audit of a key project phase during the life of the project. or post-project review that may be performed and would be
• Overall project management methodology assessment. geared toward measuring how well the project has achieved
the benefits, savings, or efficiency gains it was intended to
(Sample audit considerations for each can be found in achieve. ISACA’s Guideline G29: Post Implementation
Appendix F.) Review offers specific guidance on this type of review.20
The most important consideration for any type of internal Another approach is to audit the end results of the project
audit review is staffing the engagement with the right skill back to the originally stated objectives, or to conduct an
set. This is where the benefits of an integrated internal audit assessment of how the project went so that lessons learned
team become very clear. Using an integrated team ensures can be captured for use on future projects. The audit team
that both the functional and technical risks of the project may also perform an end-to-end process review to include
are included in the scope of the review. An integrated audit all aspects, or functionality, of both the business processes
team should include skill sets of both a business and tech- and the new information system. However the approach is
nical nature. designed, it is essential to allow an adequate stabilization
period following the launch.
The duration of the stabilization period should be deter-
Risk Assessment mined up front in the project plan. In general terms, the
A risk assessment typically involves an overview of all project stabilization usually takes on average three to six months
areas to identify the key risks that could impact project depending on the complexity of the system. It’s also impor-
delivery and determine how well they are being tracked tant for the auditors to keep in mind how quickly the project
and mitigated. This type of review is also quite common if team will disband, and to identify who will take over the
management believes the project is not progressing well, project documentation and manage the transition into a
costs are exceeding the budget, or the project has already normal maintenance or continuous improvement phase.
experienced delays. Auditing a project after the project team moves on can be
quite difficult if there isn’t adequate documentation avail-
able, or to understand why some decisions were made.
Readiness Assessment
A readiness assessment is a review that takes place at a key
stage of the project — usually upon completion of the business Key Phase Review
case, alignment phase, solution design phase, or pre-launch A key phase review, undertaken during the course of a project,
phase. The key objective for this type of review is to provide is a proactive approach often used for high-risk projects. This
objective assurance on the completeness of each phase and can include SDLC or system design reviews, or participa-
to ensure management is aware of any newly identified risks tion by the internal auditor in a “gate” or specific project
or issues before moving forward to the next step. phase review, for example. The key objective is usually asso-
ciated with assessing how closely the project management
or SDLC methodologies are followed. As indicated above,
Post-implementation Review internal auditing can work with project teams to address
A post-implementation review takes place at some prede- concerns before the system is moved into the production
termined point after the new system has gone live. There environment, when it is still relatively inexpensive to make
are many different variables to consider regarding the target corrections. Through early project involvement, internal
timing for this type of audit, including whether the system auditing can raise questions and suggestions that influence a
needs time to stabilize, how long the project team will be project in either a formal or informal way. There are two IS
available to correct issues, vendor contractual consider- auditing guidelines from ISACA that can be referenced to
ations, and postlaunch issues raised by the users. guide the IT auditor in carrying out reviews of this nature:
There are a couple of different approaches to performing
a post-implementation project review. Its purpose can be to
IS Auditing Guideline G29: Post Implementation Review,
20  
evaluate how well the project followed the organization’s
Information Systems Audit and Control Association, 2004.

16
 GTAG — Project Audit Planning

(1) Guideline G17: Effect of Non-audit Roles on the IS memos to the project steering committee could be a format
Auditor’s Independence,21 and (2) Guideline G23: System to consider. For a post-implementation review, especially if
Development Life Cycle (SDLC) Review.22 the full functionality of the system and underlying business
processes are evaluated, the formal audit report format may
be preferred.
Project Management Methodology Assessment
Auditing the overall project management methodology can
identify risks and point out weaknesses in the methodology 4.4 External Auditor Considerations
that could help the entire organization improve. For orga- Because IT and technology-related projects may
nizations that have too many projects to audit individually, have a critical impact on the organization’s financial
this type of review utilizes a more holistic approach. In addi- statements and operations, external auditors will
tion, by auditing the methodology, the internal auditor will want to know what major projects are underway in
be better prepared to audit individual projects because the an organization. Specifically, they will be concerned
PMO audit will provide a strong basis for understanding the with IT projects that could have a major impact on:
organization’s practices. • Financial statement reporting (e.g., a new SAP
Possible objectives of auditing project methodologies general ledger system).
include: • Revenue generation (e.g., order processing).
• Assessing the adequacy of project management • Inventory management.
methodologies. • Major business or IT transformations that affect
• Determining whether the methodology supports the financial data or systems that produce financial data.
full range of IT projects in the organization, from • Major regulatory requirements such as the U.S.
very small to very large. Sarbanes-Oxley Act of 2002.
• Assessing the effectiveness of management level
support provided by the PMO. (This may be articu- The CAE should engage with the external auditors to
lated in a PMO charter or mission statement.) understand their perspectives on the risks associated with
• Determining whether the PMO policies, standards, IT projects. A major risk for the organization is that the
methodologies, and processes are implemented external auditor is unaware of major projects and highlights
and executed consistently across all projects in the key control considerations of a project after the new system
organization. is already in production, when it is considerably more expen-
• Assessing the ability of the PMO to add the intended sive to modify existing controls or implement new controls.
level of value.
• Determining whether the PMO has a complete
inventory of all projects in the organization. Conclusion
• Determining whether the PPM processes are working In conclusion, “auditors should consider projects to be oppor-
effectively. tunities to exploit their core competencies in new areas,
while they help ensure the effective risk management, cost
containment, and organizational success of projects,” notes
Project Audit Reports Richard B. Lanza in an article on technology project risks
The report out from the audit team following a project review that appeared in Internal Auditor in 2002,23 which is still very
can vary depending on the type of review performed, and the relevant today. The incorporation of projects into the audit
stage of the project at which the audit team gets involved. universe helps internal audit to partner with both project
The IIA’s International Standards for the Professional Practice of managers and senior management and to have a positive
Internal Auditing 2400 series provides guidance for communi- impact towards future project success.
cating results; however, the type of review should be carefully
considered when determining what format works best within
the organization. For example, if the audit team is partici-
pating throughout the life of the project, status updates or

IS Auditing Guideline G17: Effect of Non-audit Roles on the IS

21  

Auditor’s Independence, Information Systems Audit and Control

Association, 2003.
IS Auditing Guideline G23: System Development Life Cycle
22  

(SDLC) Review, Information Systems Audit and Control Association, “Technology Projects: The Riskiest Parts of the Business,” Internal
23  

2003. Auditor, May 15, 2002, Richard B. Lanza, CPA, PMP.

17
GTAG — P
 roject Management

Appendix A – Project Types of components typically found in a methodology

Management include:
• Frameworks – composed of phases, activities, and
tasks.
A.1 Project Management Methodologies • Guidelines – define the activities required to generate
An IT project management methodology is like a toolkit deliverables.
for project teams. A good methodology explains the rela- • Techniques/Methods – provide guidance on how to
tionships among all the relevant project management and perform activities.
organizational processes. It is a comprehensive structure of • Templates and Samples – make it easier to apply
repeatable processes that provides a road map on when, how, recommended techniques.
and what events should occur in what order. For IT proj- • Roles – communicate who is responsible for what.
ects, it is based on a combination of project management and • Project Plans – lists the activities at both high and
system development best practices. Typically, it is composed detail level for the project.
of interrelated phases, activities, and tasks that are supported
by documented milestones, guidelines, techniques/methods,
templates, samples, and roles and responsibilities. A.2 Project Management Life Cycle
A methodology is necessary to: According to the Project Management Institute, there are
• Provide a standard, repeatable model approach that five phases in a project life cycle. The phases are linked by
can be used to deliver a project. the outcomes they produce — the outcome of one is the
• Promote the use of best practices that will increase a input to another.
project’s probability of success.
• Define what is happening so that it can be improved. 1. Initiating – Authorizing the project.
(According to the Software Engineering Institute 2. Planning – Defining and refining objectives and
(SEI), a process has to be defined before it can be selecting the best of the alternative courses of action
improved or made repeatable.) to attain the objectives that the project or phase was
• Increase the chances of project success and reduce undertaken to address.
known risk areas. 3. Executing – Coordinating people and other resources
• Provide a structure for project managers to manage to carry out the plan.
their projects. 4. Controlling – Ensuring that the project objectives are
• Ensure best practices are systematically deployed met by monitoring and measuring progress regularly
across projects. to identify variances from the plan so that corrective
• Provide a structure for assessing the effectiveness action can be taken when necessary.
of project outcomes and updating the methodology 5. Closing – Formalizing acceptance of the project or
with those lessons learned. phase and bringing it to an orderly end.
• Provide a structure for consistently monitoring
project performance against a consistent set of deliv-
erable requirements and performance metrics.

Initiating Planning
Processes Processes

Controlling Executing
Processes Processes

Closing
Processes

Figure 6. Major Project Life Cycle Process Groups. Source: Project Management Institute A Guide to the Project
Management Body of Knowledge (PMBOK ® Guide) - 2000 Edition, Project Management Institute Inc., 2000.
Copyright and all rights reserved. Material from this publication has been reproduced with permission of PMI.

18
 GTAG — IT Project Stakeholders

Appendix B – IT Project Stakeholders

The following is a list of potential stakeholders and their associated responsibilities. Not all of these roles will exist for every
project, and there are many other possible roles.

Stakeholder Responsibility
Steering Committee (Executive or Executive leaders (business and IT) who influence guiding principles,
Technical) strategy, and major decisions
Sponsor Person who provides the financial resources or endorsement of the project
Project Manager Person with overall project responsibility and clear lines of authority and
accountability
User (Business, IT, etc.) Those who use the outcome from the project
Project Team The team that performs day-to-day work on the project, a mix of IT and
business people
Influencers Those not directly related to the use of the project, but due to their position,
can have negative or positive influence
Project Management Office The office that provides project managers or other team members, which
may have direct or indirect responsibility for the outcome of the project
Compliance Review Boards The team that assesses special compliance or policy requirements such as the
U.S. Sarbanes-Oxley Act of 2002, local laws, etc.
IT Security Those who ensure that the final system is designed with the IT security
features to meet organizational security policies or best practices
IT Architecture Board The team that ensures that the system will be compatible with existing or
future infrastructure
Consultants and Vendors Development consultants or the applicable system vendors (e.g., SAP,
Peoplesoft, etc.)
Auditors (Finance, IT, External, and Those who perform audits and provide auditor perspective on risk
Internal)
Procurement Those who buy project materials and labor

19
GTAG — P
 MOs’ Structure, Roles, and Responsibilities

Appendix C – PMOs’ Structure, Roles, and Responsibilities

Project management offices (PMOs) are typically organized and provide support in three ways:

Organizational Level Type of Support Provided

Single Project Supports or fully manages a single, very large project such as the Year 2000
problem or a global enterprise resource planning system implementation.
Business Unit Supports many projects within a single business unit, usually within a larger, global
organization that has many business units.
Strategic/Global Supports all of the projects in an organization, regardless of which business unit
owns the project.

The roles and responsibilities of PMOs vary by organization and may include some or all of the following:
• Provide project reporting and tracking.
• Ensure executive and/or user alignment and support.
• Drive process consistency and repeatability across projects.
• Provide projects with consulting and mentoring.
• Develop, implement, and maintain a framework for effective project management, including policies, standards,
and methodologies.
• Provide project management training and mentoring.
• Provide the organization with a pool of project managers to manage projects.
• Conduct post-mortems of projects to capture and incorporate lessons learned.
• Help individual projects prepare for audits.
• Support the management of the organization’s entire collection of projects, which may be referred to as project
portfolio management.

20
 GTAG — Maturity Models

Appendix D – Maturity Models

D.1 Capability Maturity Model
The first widely accepted maturity model was the Capability Maturity Model (CMM) developed by the Software Engineering
Institute at Carnegie Mellon University in the United States. It was focused on software development.
CMM, and now many other models, use the following levels of maturity. The idea is to move from Level 1 to Level 5.
• Level 1: Initial – Few processes are defined.
• Level 2: Repeatable – Basic project management processes are established.
• Level 3: Defined – Projects use an approved tailored version of the organization’s standard software process.
• Level 4: Managed – Detailed measures are defined and controlled.
• Level 5: Optimizing – Continuous improvement is enabled.

D.2 Project Management Maturity Models

Project management maturity models provide a process and structure for assessing current project management capabilities
and developing a strategy for improvement. The following are two of the many examples of project management maturity
models.

Maturity Model Source Description

The Portfolio, Program, United Kingdom’s Uses 32 Key Performance Areas as a basis for assessing and
and Project Management Office of Government transitioning among the standard five layers of maturity.
Maturity Model (P3M3) Commerce (OGC)
Organizational Project Project Management Uses a highly structured approach for evaluating an orga-
Management Maturity Institute (PMI) nization’s maturity based on three interlocking elements:
Model (OPM3) knowledge, assessment, and improvement.

D.3 Systems Development Maturity Models

Systems development maturity models provide a process and structure for assessing current systems development capabilities
and developing a strategy for improvement. The following are two of the many examples of systems development maturity
models.

Maturity Model Source Description

Capability Maturity Software Engineering SEI developed the first major software development maturity
Model Integration for Institute (SEI) model, and this is the next generation of that model.
Development (CMMI)
The Software Process International Also known as ISO 15504, this standard provides a framework for
Improvement and Standards the assessment of software processes, and is aimed at setting out a
Capability dEtermina- Organization (ISO) clear model for process comparison.
tion (SPICE)

21
GTAG — General Project Management Best Practices

Appendix E – General Project Management Best Practices

E.1 PMBOK and PRINCE2
Project management best practices are primarily embodied in the following two guides:

Best Practice Source Description

The Project Management Project Management An internally recognized standard (IEEE Std
Body of Knowledge Institute (PMI) 1490-2003). It is the most broadly accepted set
(PMBOK) of project management practices in the world.
Projects in Controlled United Kingdom’s Office of A structured approach to project manage-
Environments (PRINCE2) Government Commerce (OGC) ment. It is the de-facto standard in the United
Kingdom and other parts of Europe.

Neither of these guides specifically targets IT projects, nor The PMBOK is consistent with standards from the
are they meant to stand alone as project management tools. International Organization for Standardization (ISO) and the
They are broad sets of fundamental practices and guidelines Capability Maturity Model (CMM). The PMI manages the
that are applicable across a wide range of industries and Project Management Professional (PMP) certification. Many
departments, and they’re meant to be customized to the government and financial organizations in the United States and
organization’s needs. They are applicable whether an orga- the United Kingdom require their managers to be PMP certified.
nization is building a bridge, developing a new service, or
implementing a new software application. The PMBOK and
PRINCE2 are different in many ways. However, both offer PRINCE2
equally acceptable foundations for developing an IT project PRINCE2 is intended as a generic, customizable, end-to-end
management framework. project management methodology. It has eight process areas:
• Business Case
• Organization
PMBOK • Plans
According to the PMI, the PMBOK describes the sum of • Controls
knowledge generally accepted within the profession of project • Management of Risk
management. “Generally accepted” means the knowledge • Quality
and practices described are applicable to most projects most • Configuration Management
of the time, and there is widespread consensus about their • Change Control
value and usefulness. The overall purpose of the PMBOK is
to provide a common lexicon within the project manage- PRINCE2 fits each process into a framework of essential
ment profession and practice for talking and writing about components that should be applied throughout a project. It
project management. covers how to organize, manage, and control projects.
The PMBOK begins with nine key project knowledge
areas:
• Integration Management E.2 ISO Standards
• Scope Management The ISO standards incorporate and address project manage-
• Time Management ment best practices for specific industries or process areas, such
• Cost Management as quality or construction management. However, ISO does
• Quality Management not have a standard dedicated to general project management
• Human Resource Management practices. The following are three examples of ISO standards
• Communications Management that include project management practices.
• Risk Management • ISO 1006:2003 provides guidance on quality in
• Procurement Management project management processes.
• ISO 9001:2005 addresses quality with respect to
These knowledge areas are further refined into 44 detailed service and product development.
processes. The PMBOK also provides guidance around project • ISO 15504 addresses project management maturity.
portfolio management and project management offices.

22
 GTAG — General Project Management Best Practices

Internal auditors in organizations that use ISO standards structuring their audit program and assessing the business
should ensure they understand which ISO standards are rele- value of the project.
vant to their industry and their organization. There are too
many ISO standards to discuss all of them in this GTAG.

E.3 COBIT Sections That Apply

To Project Management
Control Objectives for Information and related Technology
(COBIT) was developed by the IT Governance Institute, in
association with the Information Systems Audit and Control
Association. COBIT is a large and comprehensive IT gover-
nance framework that includes control objectives that could
be used to manage IT projects.
When using COBIT to plan project audits, the internal
auditor must determine which specific control objectives
from COBIT best support the audit objectives. Here we
highlight topics within COBIT’s four domains that are most
likely to be relevant during a project review, but others may
apply as well.

Plan and Organize

oo Ensure Compliance with External Requirements
oo Manage Projects
oo Manage Quality
Acquire and Implement
oo Identify Automated Solutions
oo Acquire and Maintain Application Software
oo Acquire and Maintain Technology Infrastructure
oo Develop and Maintain Procedures
oo Install and Accredit Systems
oo Manage Changes
Deliver and Support
oo Define and Manage Service Levels
oo Manage Third-party Services
oo Manage Performance and Capacity
oo Ensure Continuous Service
oo Ensure Systems Security
oo Educate and Train Users
Monitor and Evaluate
oo Monitor and Evaluate IT Performance
oo Monitor and Evaluate Internal Control

E.4 VAL IT
The Val IT Framework from the IT Governance Institute
provides auditors with a powerful tool for assessing the
business value of a project. Val IT offers a comprehensive,
consistent, and coherent approach that helps all levels of
management optimize the realization of value from IT invest-
ments.24 Auditors can use this framework as a basis for

24  
Val IT, IT Governance Institute, 2008.

23
GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Appendix F – Internal Auditor’s Questions for Reviewing an IT Project

The following table is a suggested list of audit questions that can be used in the assessment of the five key focus areas that have
been highlighted throughout this GTAG. These questions have been adapted from a Lafarge internal audit work program.

Business Case and Alignment

 Area Criteria
1 — Business Case- Investment / Benefit Realization

1.1 Business case There is an agreed-upon business case for the project.
management
It is updated, and includes lower levels of details as information becomes available.
Realistic assumptions are being made about costs and benefits.
Assumptions are documented and agreed-upon.
Assumptions are actively proven or disproved as the project progresses, and appro-
priate action is taken as a result.
1.2 Project costs The project management team is confident in the estimates.
A standard estimating model is used for all common pieces of work.
It is clear who needs to agree with and understand the model.
Extra budget has been allocated to speed up or fast-track development projects to
allow for testing out the approach, environment, etc.
Estimates are included in the budget for both staff and nonstaff costs (hardware / soft-
ware external/internal resources, developments, end-to-end testing, quality assurance,
benefits realization follow-up, vendor costs, operational costs, etc.).
There is a definition of what contingency is to be used. If an issue arises, there is a
plan for how it will be addressed.
The estimates have been reviewed by a qualified third party.
1.3 History Changes in project costs have been made since the original business case.
Changes have been made, if so, understand why.
1.4 Timing of costs The estimated timing of costs is appropriate. Understand if it is possible to postpone
some costs.
Timing of costs has been changed, if so, understand why.
1.5 Type of benefits Types of benefits (e.g., cost reduction, increased revenue, qualitative) are clearly
articulated.
The realization of benefits is dependant on external factors.
How dependencies should be approached is defined.
The benefits are aligned with the current scope of the project.

24
 GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Business Case and Alignment

 Area Criteria
1.6 Realization of It is clear how benefits will be measured (e.g., direct bottom line cost reduction, staff
benefits reduction or cost reallocation).
The responsibility for achievement of benefits is clearly defined in terms of who will
do what.
The owners have approved the benefits as reasonable and achievable.
1.7 Time plan A timeline for benefit realization is stated.
The timing seems appropriate.
Understand if there are any possibilities of accelerating the benefits realization.
2 — Project Plan and Approach

2.1 Objective and scope The scope of the project is clearly defined, and it includes sufficient level of detail.
There is an up-to-date and communicated project charter.
There is a common understanding of scope by both the business and the project.
There is an agreed-upon procedure for changing the scope, which was designed at the
outset of the project.
2.2 Estimates, timeline, The current estimates are clearly communicated to the project group, sponsor,
and scope steering group, and project office.
Understand if estimates have changed over time, and why.
The project has been reevaluated based on business case updates.
2.3 Organization Each role in the project is defined.
The project organization is defined.
Everyone on the project knows and understands his or her role.
Understand if there are any incentives attached to project success and the impact.
2.4 Deliverables The content and structure of each deliverable of the phases are documented.
The purpose of the deliverables are clearly understood and documented.
All project signatories are aware of the required deliverables sign-off.
The format of the deliverables been discussed and agreed-upon with the signatories.
Appropriate experts have reviewed key deliverables.
2.5 Dependencies Tasks outside the project are clearly documented and understood. The plans for these
tasks have been developed and agreed-upon.
Checkpoints are defined in advance, along with what will be produced.
The planning assumptions are understood, documented, and agreed-upon.

25
GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Business Case and Alignment

 Area Criteria
2.6 Time plan and There is an overall project plan that links together all the sub-project plans.
activities
Every stream within the project has a detailed plan with visible milestones. Check if
this only applies to critical areas.
Each area has a clear view of the end result and what is required to get there.
The main pieces of work have been identified and the relationship between them is
documented.
Each piece of work has a clear focus and owner.
All inter-project and external dependencies have been identified and due dates and
owners are defined.
There is a fast track or pilot project to prove the methodology, deliverables, environ-
ment, etc.
The pilot project run is small, discrete, and representative.
The owners of the pieces of work have agreed to the plans.
The planned days/weeks allow for holidays/training.
The plan reflects learning curves/knowledge transfer.
The plan allows for schedule contingency between each main piece of work as well as
at the end of each phase.
The plan includes sufficient lead-time for phase set-up tasks (e.g., environment, stan-
dards, and procedures.).
Appropriate reviews and sign-off time is incorporated into the plan.
3 — Project Communication and Coordination

3.1 Communication and Everyone knows why we are doing this and the timeline of events.
change management
Everyone knows how it will affect him or her.
3.2 Organization Each role in the organization is defined.
Everyone knows how his or her role relates to the process on the whole.
3.3 Dependencies All inter-department and external dependencies have been identified.
Management is releasing the necessary resources to work on the project.
Management is willing to halt other projects/areas of work if they conflict.
3.4 Shared Programs The project has sponsors or representatives from each affected area.

26
 GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Business Case and Alignment

 Area Criteria
3.5 Current status Understand the current status of the project with regard to time, cost, and scope, and
whether there are any deviations from the project definition.
Understand the key concerns with respect to status.
Understand why any deviations have occurred.
Reasons behind deviations were identified as risks before they occurred.
Corrective actions have been taken to address deviations, risks, and issues.
3.6 Work plan The work plan has been updated regularly.
The project estimates are accurate and key milestones have been met on time.
Key tasks to be completed are identified, and the critical path or must-have list for
go-live has been identified.
A plan to handle overruns if expected has been developed.
3.7 Risk handling A risk assessment has been performed, documented, and communicated.
It includes mitigation actions / contingency plans and those accountable.
The risks are understood by the business.
The risks and actions to mitigate them are proactively managed.
Risks are reviewed regularly with the business.
Issues have a clear owner for resolution.
3.8 Dependencies on The plan incorporates a mechanism for the coordination of changes resulting from
other project/areas other business/systems projects.
Service level agreements have been specified for support areas.

IT Solution and Change Management

Area Criteria
4 — Process Design

4.1 Business scope Scope — in terms of business units, locations, and business rules — is defined and
validated.
4.2 Process and The process design is documented through business scenarios and business process
supporting design design documents.

Business scenarios are documented, tested successfully, and signed off by business
representatives.
5 — Configuration and Developments

5.1 Translation All screens and customizing is documented.

5.2 Configuration Configuration of critical tables are reviewed for completeness, and fully documented.

27
GTAG — I nternal Auditor’s Questions for Reviewing an IT Project

IT Solution and Change Management

Area Criteria
5.3 Programs Functional design is complete, up to date, and agreed-upon with business
representatives.
Technical design is complete, according to specifications, and successfully unit-tested,
and acceptance is tested by the project team.
Specific programs are developed according to standards.
Specific programs are unit tested.
Programs are migrated to production platform or environment.
5.4 Interfaces Functional designs for interfaces are complete, up-to-date, and agreed to.

Technical designs for interfaces are complete and up-to-date.

Reports are developed according to design, successfully unit-tested, and accepted by
the project team.
Interfaces are tested “end-to-end” with the production platform.

The functional error-handling process is defined, developed, and tested.

There are no outstanding “urgent” or “high” issues with interfaces.
6 — User Acceptance Tests

6.1 User acceptance All business scenarios are successfully executed and signed-off. All user acceptance
tests tests are complete and scripts signed-off.
There is adequate business involvement to ensure realistic testing.
6.2 Issues list All functional gaps noted in the issues list are closed and resolutions are agreed.
6.3 Batch schedule Daily, weekly, monthly, quarterly, and annual batch schedules are designed and vali-
dated with project and technical teams.
Job failure instructions, from a functional perspective, are defined (e.g., skip job,
rerun next day or hold schedule).
6.4 Issues remaining at Functional team leads have agreed with key business representatives which issues will
go-live not be fixed until after go-live, and work-arounds if necessary are defined.
Where required, workarounds have been defined and communicated to the training
and help desk/support groups.

28
 GTAG — Internal Auditor’s Questions for Reviewing an IT Project

IT Solution and Change Management

Area Criteria
7 — Data Conversion and Cut-over

7.1 Data conversion The data conversion plan and quality of converted data is proven through trial
plan conversions and dry runs. Data owners for all data conversions are established.
The data converted reconciles with data in the legacy systems.
The quality of dry run-converted data is verified by data owners.
The conversion plan dependencies and critical path are tested.
Profiles required for manual data loads/checking are available and give required
access.
There are no outstanding “urgent” or “high” issues with the dry run.
7.2 Parallel data Procedures for all data where parallel maintenance is required are written.
maintenance Checks are in place to make sure parallel maintenance is carried out correctly.
7.3 Data loading All pre go-live data loads are executed.
Data converted reconciles with data in legacy systems.
The quality of converted data is verified by data owners.
There are no outstanding “urgent” or “high” issues with the data load.
7.4 Go-live plan The go-live plan is developed and communicated to all impacted project and business
personnel.
The legacy batch schedule is ready.
Legacy access profiles are amended to ensure users do not continue to use legacy
systems by mistake.
Timing and participants of go/no-go meetings are agreed-upon.
Fallback plans are developed and agreed-upon.
7.5 Reconciliation Financial balances reconcile to legacy systems. Balances are loaded and can be recon-
ciled to legacy systems.
Procedures are in place to explain or fix discrepancies.
8 — Technical Infrastructure

8.1 User interface All user locations are identified.

The user interface is installed and has been checked on each PC.
Logon procedures are checked.
All update procedures are documented and communicated.
8.2 Printers All printer locations are identified, and printers are set up and tested.
All printers are established in the different systems.
All printers can print from the different systems.

29
GTAG — I nternal Auditor’s Questions for Reviewing an IT Project

IT Solution and Change Management

Area Criteria
8.3 Electronic output All fax and other electronic output formats are agreed-upon and tested.
A production test is completed to outside fax line and electronic data interchange
(EDI) recipients.
8.4 Batch schedule Nightly and monthly batch schedules are checked.
All server/directory destinations for interfaces are set up to point to production
systems.
There are no outstanding “urgent” or “high” issues.
8.5 Error handling Procedures for checking that errors are logged (batch interface) are in place.
procedures
Batch interruption re-start procedures are agreed-upon and tested.
Procedures for communicating errors to the business are agreed-upon.
8.6 Communication All communication links (e.g., LAN, WAN) are tested.
links
Bandwidth supports peak data volumes.
Fallback procedures are in place and tested.
8.7 System sizing All infrastructure components that form part of the overall technical architecture is
sized and tuned to accommodate peak activity and predicted growth rate.
Hardware, software, and applications are tuned for go-live.
8.8 Performance tests Performance tests have been conducted, and performance is acceptable for key busi-
ness processes.
8.9 System performance Post go-live, online, and batch system performance monitoring and tuning procedures
are in place.
8.10 Disaster recovery Procedures are in place for downtime, and a disaster recovery plan is in place.
Procedures successfully tested.
8.11 Online system Online system availability and maintenance slots are agreed-upon with the business.
availability and
maintenance slots
8.12 Security profiles Security profiles are defined and implemented for IT support staff.
The production environment is secured.
8.13 Interfaces The interface technical set up is complete and tested.

30
 GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Business and User Readiness 

Area Criteria
9 — Business Simulation

9.1 Preparation All business scenarios are written (capitalize on user acceptance testing).
The technical environment is ready.
All necessary data are converted in the simulation environment.
Users and profiles are ready.
9.2 Completion All business scenarios with “urgent” or “high” issues are successfully executed.
There is adequate business involvement to ensure realistic testing.
10 — Data Maintenance Post Go-live

10.1 User ownership Data types are inventoried and owners agreed-upon.

The actual persons who will perform maintenance are appointed and trained.
10.2 Data maintenance Procedures exist for each type of add/update.
Procedures cover updating of any related trans-codification tables.
Procedures have been communicated to all impacted users.
11 — Roles and profiles

11.1 User profiles Profile design is agreed-upon by the project team and business representatives.
Profiles are developed and tested successfully.
There are no outstanding “urgent” or “high” issues with profiles.

11.2 Business risks Key business risks are identified and covered through systems features or procedures.
There are no outstanding “high” issues.

11.3 System user access All profiles are developed and tested for production and non-production environments.
The business signs off on who receives what access.
The business controls approval on segregation of duties.
All user profiles are set up, including conversion and support roles.

11.4 Profile maintenance Procedures for maintaining profiles after go-live are developed, approved, and distrib-
uted to impacted personnel.
12 — User Readiness and Training

12.1 User impact All users understand how their job will be impacted by the solution.
All affected users have received job change information.
12.2 User training and All affected users have attended training.
competence
Trainees have demonstrated competence in using the solution through the completion
of training exercises.
Extra coaching and support is scheduled for those users post go-live.

31
GTAG — I nternal Auditor’s Questions for Reviewing an IT Project

Business and User Readiness

Area Criteria
12.3 Interface errors Users responsible for correcting interface errors have been identified and have been
trained on the procedures.
12.4 Support tools Users have access to support tools
12.5 New codes and form Customers/suppliers are informed of all new codes, form layouts, etc.
layouts

Implement - Transition - Post Implementation

Area Criteria
13 — Resource Staffing and Key Roles

13.1 Competence The required skills are understood, documented, and updated.
requirements and
fulfillment The required skills are covered by people assigned to the project.
The project is competing with other projects/initiatives for key competencies/
resources. If so, understand the impact.
There is a training program to build skills that are missing.
13.2 Competence Key resources have been localized in the project premises, and/or the project team
localization members are all located together.

13.3 Resource mix The project has sufficient full-time resources.

The internal vs. external resource mix is clear. There is a clear process for knowledge
transfer if the external support is high.
Agreements have been put in place for external resources (e.g., time and materials, or
pay for realized benefits).
13.4 Staffing of key roles The staffing of all areas receives sufficient priority — or is the skilled staff located in
one key area?
Knowledgeable resources are best placed to maximize their contribution to the project.
The following roles are filled with staff with the right skills: technical architect, data
architect, business architect, functional architect, and conversion/migration architect.
14 — Implementation Into Business Areas

14.1 Roles projects/busi- The business area understands their role in each phase of the project, and is prepared
ness areas for the implementation.
Each business area has a dedicated resource to work with the project.
The decision-making process is clearly defined.
The business area understands their role in the decision-making process.
14.2 Plans and resources There are plans and resources for training, roll-out, follow-up, and sign-off.

32
 GTAG — Internal Auditor’s Questions for Reviewing an IT Project

Implement - Transition - Post Implementation

Area Criteria
15 — Implementation into IT Production and Maintenance

15.1 IT production There is a plan for transferring knowledge.

The production team has agreed to a deployment plan.
There are plans to ensure capacity.
15.2 IT maintenance There is a plan for transferring knowledge.
Maintenance has agreed to a deployment plan.
There are plans to ensure capacity.
15.3 Implementation The conversion dates been changed. If so, why?
16 — Transition to Support

16.1 Support strategy The overall support strategy is agreed-upon.

The first-level support members are identified and trained on the required tools.
The second-level support members are identified and trained on the required tools.
16.2 Change requests and The process for assessing and implementing change requests is agreed-upon and
fix procedures communicated (e.g., impact analysis, funding).
The process for applying fixes and change requests is agreed-upon and communicated.

16.3 Support processes Support numbers and guidelines for what information needs to be recorded if a
and contacts problem is found have been communicated to users.
The business is aware of on-site support contacts.
16.4 System usage, System usage measures (i.e., the system is being used, and it’s working) are defined
control measures, and agreed. Procedures are in place for capturing and reporting information.
and review meetings
Daily post go-live review meetings are arranged.
17 — Business Continuation Plans

17.1 Business continua- Business continuation plans, in the event of loss of system, are developed and agreed-
tion plans upon with project and business groups.
Fallback plans are established to address procedures to take when the system becomes
available again, to ensure items are not processed twice and financials are updated.
Any required manual forms/other systems are in place to support fallbacks.
The process for triggering fallback plans (i.e., who decides and who communicates) is
defined and agreed-upon.

33
GTAG — A
 bout the Authors

About the Authors

Steve Stein, CIA, PMP, CISA, CISSP, CFE, CGEIT
Steve Stein is the global IT audit manager for Hewlett-Packard’s Internal Audit Department. He is respon-
sible for the strategic planning and management of the IT audit function worldwide. Stein has 20 years of
IT project management, consulting, and audit experience across many industries, including U.S. govern-
ment, high-tech, and pharmaceuticals. He has extensive experience implementing and auditing SAP R/3
application implementations for global organizations, and assessing earned value project management
systems. Stein was formerly a senior manager in KPMG’s Information Risk Management group. He was
awarded The Institute of Internal Auditors’ William S. Smith Certificate of Honor in 2004 for his perfor-
mance on the Certified Internal Auditor exam. He is a former U.S. Air Force Captain and graduate of the
U.S. Air Force Academy, where he studied engineering and science.

Karine Wegrzynowicz, CIA, CISA

Karine Wegrzynowicz is an internal audit director with Lafarge Group Audit. Her responsibilities include
oversight of auditing for IT and other operational functions on a global basis for Lafarge, a Paris-based
international world leader in the building materials industry. Wegrzynowicz has more than 20 years of
internal audit, IT, and operations experience in the airline, automotive and financial services indus-
tries. She has served The Institute of Internal Auditors and Information Systems Audit and Control
Association at both the local chapter and international levels and is currently a member of The IIA’s
Advanced Technology Committee.

Reviewers
The IIA thanks the following individuals and organizations who provided valuable comments and added great value to this
guide:
• Professional Practices Advisory Council:
oo Advanced Technology Committee
oo Board of Regents
oo Committee on Quality
oo Internal Auditing Standards Board
oo Professional Issues Committee
oo Ethics Committee
• IFACI (Unité de recherche informatique), France
• The IIA Norway (NIRF) IT Audit Speciality Group (IT nettverket)
• The Institute of Internal Auditors - UK & Ireland
• Ken Askelson, USA
• Clyde Batten, Nedbank Group Limited, South Africa
• Lily Bi, The Institute of Internal Auditors, USA
• Anders Blix, EDB Business Partner, Norway
• Lionel Guillou, Euroclear, Belgium
• F. M. Hallinan, Chevron Phillips Chemical Co. LLP, USA
• David Lione, Consultant, USA
• Michael Lynn, AXA Technology Services, USA
• Steve Mar, Resources Global Professionals, USA
• Tom Margosian, Ford Motor Co., USA
• Kurt Milne, IT Process Institute, USA
• Dr. Ulrich Hahn, independent audit expert, Germany
• Jacques Lourens, Nedbank Group Limited, South Africa
• Cesar Martinez, City of El Paso, USA
• Steve Hunt,Crowe Horwath LLP, USA
• James Reinhard, Simon Property Group Inc., USA
• Joe Zhou Xiaowei, General Motors, China

34
Cffb`e^]fiÕ\o`Yc\@KXl[`kjkX]Ôe^6
=ifdjdXcc$jZXc\#]fZlj\[@KXl[`kk\jk`e^Xe[Xjj\jjd\ek`e`k`Xk`m\jkfcXi^\i$
jZfg\#Zfdgc\k\@KXl[`kZf$jfliZ`e^Xjj`jkXeZ\#flik\Xdf][\[`ZXk\[@KXl[`k
jg\Z`Xc`jkj_\cgpflXZ_`\m\Zfjk\]ÔZ`\eZ`\jk_XkXi\dfi\`dgfikXekk_Xe\m\i`e
kf[XpËj\Zfefd`ZZc`dXk\%N`k_dfi\k_Xe,''i`jbXe[fg\iXk`fejgif]\jj`feXcj`e
e\Xicp(''f]ÔZ\jeXk`fen`[\#n\Ëi\XmX`cXYc\n_\i\m\iXe[n_\e\m\ipfle\\[lj%

Fli]lccjl`k\f]Zf$jfliZ\[@KXl[`kj\im`Z\j`eZcl[\j1
4 :f$jfliZ\[@KXl[`k 4 G\e\kiXk`fek\jk`e^
4 Gifa\ZkdXeX^\d\ek&Xjj\jjd\ek 4 9lj`e\jjZfek`el`kpXjj\jjd\ek
4 J;C:i\m`\nj 4 G:@;XkXJ\Zli`kpJkXe[Xi[j\im`Z\j
4 J8J.'Xl[`k! 4 JXiYXe\j$Foc\p@Kk\jk`e^
4 @Kj\Zli`kpXe[ZfekifcjXjj\jjd\ek  

nnn%ijddZ^cX[i\p%Zfd&@K$i`jbsKIDJ7ijd`%Zfds/''%-+/%+'*'

JZXcXYc\%
@ek\^iXk\[%
FYa\Zk`m\%

IJDDZ>cX[i\p`jk_\f]ÔZ`XcXZZflek`e^#kXoXe[Ylj`e\jjZfejlck`e^Ôidf]K_\G>8f]8d\i`ZX%
!8l[`kXe[Xkk\jkj\im`Z\j[\c`m\i\[YpDZ>cX[i\pGlcc\eCCGXgXike\i$fne\[:G8Ôid %IJDDZ>cX[i\pfg\iXk\j`eXeXck\ieXk`m\giXZk`Z\jkilZkli\n`k_DZ>cX[i\pGlcc\eCCG%K_fl^_
j\gXiXk\Xe[`e[\g\e[\ekc\^Xc\ek`k`\j#k_\knfÔidjnfibkf^\k_\ikfj\im\Zc`\ekjËYlj`e\jje\\[j%IJDDZ>cX[i\p@eZ%Xe[DZ>cX[i\pGlcc\eCCGXi\d\dY\ijf]IJD@ek\ieXk`feXcÇXe
X]Ôc`Xk`fef]j\gXiXk\Xe[`e[\g\e[\ekc\^Xc\ek`k`\j%Ÿ)''0IJDDZ>cX[i\p@eZ%#8ccI`^_kjI\j\im\[
GTAG 12: Auditing IT Projects
Failure is not an option when it comes to your organization’s IT projects. A project that goes over
budget, falls behind schedule, does not achieve objectives, or is cancelled altogether can have
a severe impact. Internal auditors can -- and should -- play a role in their organization’s key IT
projects!
The purpose of this GTAG is to provide you with an overview of techniques for effectively
engaging with project teams and project management offices (PMOs) in order to assess the risks
related to IT projects. This guide covers:
• How to outline a framework for assessing project related risk.
• Examples of common project management risks.
• How the internal audit function can actively participate in the review of projects while
maintaining their independence.
• Five key components of IT projects for internal auditors to consider for building an audit
approach.
• Top 10 factors for project success.
• Types of project audits.
This guide also includes sample questions for reviewing IT projects.

We’d like your feedback! Visit the GTAG 12 page under www.theiia.org/gtags to rate this Practice
Guide and submit your comments.

ISBN: 978-0-89413-663-4
Order Number: 2018.dl
IIA Member Free
GTAGs are Practice Guides
Nonmember US $25
aligned under the International
www.theiia.org
Professional Practices Framework