Chapter Four

INFORMATION TECHNOLOGY
DEPLOYMENT RISKS
Developing Strategic Plans
Serves as primary guideline for allocating
resources.
Keeps the organization headed in a
profitable direction.
Begins with a vision.
Objectives Strategy Policies
Mission Objectives Strategy Policies
Information
Technology Plans
Must Complement &
Support Company
Plans
Mission
The IT Auditor & Strategic Plans
The IT auditor should look for evidence of a
prescribed, documented IT strategic
planning process.
The existence of an ongoing process of this
nature indicates that the company is
constantly and diligently seeking an optimal
fit between the information technology
infrastructure and the organizations
overall goals.
Example: Ben & Jerrys Mission Statement
Ben & Jerrys is dedicated to the creation &
demonstration of a new corporate concept of
linked prosperity. Our mission consists of three
interrelated parts. Underlying the mission is the
determination to seek new and creative ways of
addressing all three parts while holding a deep
respect for individuals inside and outside the
company, and for the communities of which they
are a part.
Product: To make, distribute, and sell the finest quality all
natural ice cream and related products in a wide variety of
innovative flavors from Vermont dairy products.

Economic: To operate the Company on a sound financial
basis of profitable growth, increasing value for our
shareholders, and creating career opportunities and financial
rewards for our employees.

Social: To operate the company in a way that actively
recognizes the central role that business plays in the
structure of society by initiating innovative ways to improve
the quality of life of a broad communitylocal, national,
and international.

Ben & Jerrys IT Mission Statement
Might Be:
The Information Systems function intends to offer
high-quality, innovative information processing
and management services to internal and external
information consumers, while providing a reliable,
responsive, and leading-edge technology
infrastructure throughout the entire organization
aimed at supporting new and creative ways of
addressing the companys three-part mission
statementcomprised of product, economic and
social components.
IT Objectives might be:
1. Create an atmosphere that embraces innovation and
change.
2. Apply computer hardware and software technologies to
opportunities that promote prosperity.
3. Incorporate an enterprise-wide information system to
facilitate the intra-company coordination of business
activities.
4. Develop a technology-based communications network
capable of linking suppliers, customers, and employees
into a seamless, virtual and extended enterprise.
IT Strategy might be:
The IT function will utilize a decentralized, organic form of
organization that is adaptable and responsive to the dynamic
nature of the Company. The IT function will include a
Chief Information Officer (CIO) who, in coordination with
other executive officers throughout the Company, will
determine the precise structure of the IT function, which is
expected to change over time depending on Company
needs. The CIO, along with his/her delegates, will strive to
cooperate and coordinate with all internal information
consumers to ensure that the Companys information system
is fully integrated on an entity-wide basis, as well as listen
and respond to external constituents to ensure that the
Companys business processes and related information
technology infrastructure meet the ever-changing needs of
the broader community of information consumers.
Important Policy Areas for IT Functions

1. Planning Policies
1. Responsibility (who is involved with
planning?)
2. Timing (when does planning take place?)
3. Process (how should planning be conducted?)
4. Deliverables (what planning documents are
produced?)
5. Priorities (what are the most to least critical
planning issues?)


Important Policy Areas for IT Functions
2. Organizational Policies
1. Structure (what is the organizational form of the IT
function?)
2. Information Architecture (is the infrastructure
aligned with the firms mission?)
3. Communication (are the IT strategy and policies
known by all affected parties?)
4. Compliance (are all external regulations and laws
being addressed?)
5. Risk assessment (are IT risks identified, measured
and controlled?)

3. Human Resource Policies
1. Training (what kind of training is provided and to
whom?)
2. Travel (what are the travel guidelines and priorities?)
3. Hiring (who determines needs and who screens
applicants?)
4. Promotion (what are the guidelines and how does the
process work?)
5. Termination (what are voluntary and involuntary
termination guidelines?)

Important Policy Areas for IT Functions
4. Software Policies
1. Acquisition (how is software acquired from outside
vendors?)
2. Standards (what are the software compatibility
standards?)
3. Outside contractors (should contractors be used for
software development?)
4. Changes (how to control and monitor the software
change process?)
5. Implementation (how to handle conversions, interfaces,
and users?)

Important Policy Areas for IT Functions
5. Hardware Policies
1. Acquisition (how is hardware acquired from outside
vendors?)
2. Standards (what are the hardware compatibility
standards?)
3. Performance (how to test computing capabilities?)
4. Configuration (where to use client-servers, personal
computers, and so on?)
5. Service Providers (should third-party service bureaus
be used?)

Important Policy Areas for IT Functions
6. Network Policies
1. Acquisition (how is network technology acquired from
outside vendors?)
2. Standards (compatibility of local area networks,
intranets, extranets, and so on?)
3. Performance (how much bandwidth is needed and is
the network fast enough?)
4. Configuration (use of servers, firewalls, routers, hubs,
and other technology?)
5. Adaptability (capability to support emerging e-business
models?)

Important Policy Areas for IT Functions
7. Security Policies
1. Testing (how is security tested?)
2. Access (who can have access to what information and
applications?)
3. Monitoring (who monitors security?)
4. Firewalls (are they effectively utilized?)
5. Violations (what happens if an employee violates
security?)

Important Policy Areas for IT Functions
8. Operations Policies
1. Structure (how is the operations function structured?)
2. Responsibilities (who is responsibility for transaction
processing?)
3. Input (how does data enter into the information
system?)
4. Processing (what processing modes are used?)
5. Error Handling (who should correct erroneous
input/processing items?)

Important Policy Areas for IT Functions
9. Contingency Policies
1. Backup (what are the backup procedures?)
2. Recovery (what is the recovery process?)
3. Disasters (who is in charge and what is the plan?)
4. Alternate Sites (what types of sites are available for off-
site processing?)
Important Policy Areas for IT Functions
10. Financial and Accounting Policies
1. Project Management (are IT projects prioritized,
managed, and monitored?)
2. Revenue Generation (should services be sold inside or
outside the organization?)
3. Technology Investments (are the investment returns
being properly evaluated?)
4. Funding Priorities (where to most effectively allocate
resources?)
5. Budgets (are budgets aligned with funding levels and
priorities?)

Important Policy Areas for IT Functions
Planning Process
Follows a clearly defined path:
Vision
Mission
Objectives
Strategy
Policies

Planning Process increases the likelihood that the
company is making the most efficient & effective
use of IT throughout the organization



Red Flags for IT Auditors
The following are planning risks indicators,
should trigger red flags for the IT auditor.
Key Planning Risk Indicators

1. A strategic planning process is not used.
2. Information technology risks are not
assessed.
3. Investment analyses are not performed.
4. Quality assurance reviews are not conducted.
5. Plans and goals are not communicated.
Key Planning Risk Indicators

6. Information technology personnel are disgruntled.
7. Software applications do not support business
processes.
8. The technology infrastructure is inadequate.
9. The user community is unhappy with the level of
support.
10. Managements information needs are not met.
CobiT Guidelines
Guidelines suggest eleven processes should
be incorporated into IT strategic plans.
Each process is integrated throughout IT
policy areas.
Processes designed to manage the key IT
risks.
11 Processes
1. Develop a strategic IT plan.
2. Articulate the information architecture.
3. Find an optimal fit between IT and the
companys strategy.
4. Design the IT function to match the
companys needs.
5. Maximize the IT investment.
6. Communicate IT policies to the user
community.
11 Processes
7. Manage the IT workforce.
8. Comply with external regulations, laws, and
contracts.
9. Conduct IT risk assessments.
10. Maintain a high-quality systems development
process.
11. Incorporate sound project management
techniques.
Balanced Scorecard
Concept introduced in 1996 by Kaplan &
Norton

Scorecard measures financial and
non-financial performances

4 Perspectives of Scorecard
1. Financial
Non-financial indicators:
2. Customer satisfaction
3. Internal processes
4. Organizational Learning and Growth
Three Layered Structure
3-Layered Structure was devised for each
of the 4 perspectives:

1. Mission

2. Objectives

3. Measures
More than Performance Measure
Scorecard evolved into an intra-
organizational management system to:

Facilitate the establishment of long term strategic
goals.

Communicate the goals throughout the firm.

Align the initiatives and incentives to the goals.

Allocate resources to match the goals.

Gain feedback and learning about the strategy.
IT Function Scorecard
Use the balanced scorecard to plan & monitor
IT performance:

Financial Organizational
=
Performance Contribution

Examples: ROI, Discounted Cash Flow, Before and after
transaction costs of IT projects.
IT Function Scorecard

Customer User
=
Satisfaction Satisfaction

Examples: Surveys of user attitudes for ease of use,
system reliability, and perceptions about the IT
staff.

IT Function Scorecard

Internal Operational
=
Processes Performance

Examples: Number of security breaches, number of
backlogged requests, % of downtime.

IT Function Scorecard

Learning Adaptability
& = &
Growth Scalability

Examples: Resources expended on developing
interfaces, ease of integrating new technology,
and ability to keep pace with organizations IT
growth.



User
Satisfaction







Adaptability &
Scalability






Organizational
Contribution
IT Function

Strategy

IT Function Scorecard
Operational
Performance

Project Management
Sound Techniques apply to most situations
Structure minimizes risk of failure:
Late delivery
Cost overrun
Lack of functions
Poor quality
IT auditor should check that project
management techniques are employed.
Project Manager
First step is to assign project to a manager
Needs experience in area
Needs skill at managing projects
Must work well with staff on planning and
executing the project.
Project Life Cycle Phase One
Plan the Project

Set the Time, Cost & Scope
Identify resources
Articulate outcome
Work with specialists
Determine the WBS Work Breakdown
Structure

Project Life Cycle Phase Two
Schedule the Project

Create Time Table for each activity.
Gantt Charts
Critical Path Analysis
Critical Math Method
Microsoft Project

Project Life Cycle Phase Three
Continuous Monitoring

Use benchmarks, milestones, deliverables.
Frequency varies by project.
Rule of Thumb: Determine the maximum
percent deviation allowed & monitor
activities at the half-way point.
Project Life Cycle Phase Four
Controlling

Keep project moving
Adjust to unexpected issues
Continually adjust the plan
Project Life Cycle Phase Five
Closing the Project

Obtain client acceptance in writing
Release and evaluate project personnel
Identify & reassign remaining project assets
Evaluations of project
Chronicle project history
Key Project Risk Indicators
1. Management does not use a formal project
management methodology.
2. Project leaders are not adequately experienced at
managing projects.
3. Project leaders have insufficient domain expertise.
4. Project teams are unqualified to handle the project
size/complexity.
5. Project team members are dissatisfied and
frustrated.
Key Project Risk Indicators
6. Projects do not have senior-level executive
support.
7. Projects do not include input from all affected
parties.
8. Project recipients are dissatisfied with project
outcomes.
9. Projects are taking longer to develop than
planned.
10. Projects are costing more than budgeted.
Acquiring Software
IT auditor should determine if the new
application would fit into the companys
strategic plan.
There should be a formal software
application acquisition policy.
Needs must be identified and prioritized.
Determine which applications can be
developed in-house, and which to purchase.
Total Cost of Software
Price of acquisition
User training
Multiple licenses
Service and support
Future upgrades
Software modifications
Key Acquisition Risk Indicators
1. Software acquisitions are not mapped to the
strategic plan.
2. There are no documented policies aimed at
guiding software acquisitions.
3. There is no process for comparing the develop
versus purchase option.
4. No one is assigned responsibility for the
acquisition process.
5. Affected parties are not involved with assessing
requirements and needs.
Key Acquisition Risk Indicators
6. There is insufficient knowledge of software
alternatives.
7. Security features and internal controls are not
assessed.
8. Benchmarking and performance tests are not
carried out.
9. Integration and scalability issues are not taken
into account.
10. Total cost of ownership is not fully considered.
Developing Software
Information Systems Development Proposal
formal documentation of requested
project.

Steering Committee reviews each proposal.

Feasibility Group studies potential projects.
Feasibility Study
Recommends to the Steering Committee
Provides preliminary assessment

Technical Feasibility: Whether current, affordable
and reliable technology can be reasonable applied t
the project.

Financial Feasibility: Calculates return based on
company policy.

Cultural Feasibility: Do the employees have
skills to run the system? Will they use it? Are
there legal or regulatory concerns?

Feasibility Report
Feasibility group prepares report to make a
recommendation on the project.
Report is submitted to Steering Committee.
Steering Committee assigns project to Project
Leader.
Project Leader assembles Project Team.
Includes functional area representatives
Includes at least one senior lever manager
Additional Systems Development Issues
Business Process Analysis
Must complete before starting technical
development.
Use Various modeling techniques.
Develop and consider alternative business
process designs.
Look to external sources.
Compare models.
Select best model.


Additional Systems Development Issues
Development & Testing

Create Libraries in a secured area of computer.
Create secure places for code and data.
Prevent destruction and/or alterations.
Company must have security procedures
continuously monitored.



Development, Test and Production
Libraries
Development
Library

No Data

Development
Source Code

Programmers
Only

Test
Library

Test Data

Test
Object Code

Programmers
& Users

Production
Library

Live Data

Production
Object Code

Users
Only

Secure Handoff

Secure Handoff

Additional Systems Development Issues
Training & Documentation
Training should:
Take place early
Be all-encompassing
Continue throughout project life cycle

Documentation should:
Be complete for entire project and all programs
Include user manuals



Key Development Risk Indicators
1. Development projects are not aligned with the
strategic plan
2. Feasibility studies do not consider the following
areas:
Technical feasibility
Financial feasibility
Cultural feasibility
3. Senior management and users are not involved
4. Business process analyses are not performed
Key Development Risk Indicators
5. Alternative designs are not compared
6. Separate development, test, and production
libraries are not used
7. Security and control features are not designed into
the system
8. Conversion and interface issues are not taken into
account
9. System testing is inadequate
10. Training and documentation is poor
Changing Software
Change Request
Specifies the change
Justifies the need
Approvals given
All parties agree change is necessary
Change is congruent with Strategic Plan
Submitted to IT



Change Requests
IT logs in the requests & assigns tracking
number
Software Change Committee reviews and
prioritizes
May refer to a feasibility group
Change is assign to IT staff person(s)

Change design & programming
Follow same structure as in new
development
Secured procedure of separate development,
test, and production libraries
Incorporated security & control procedures
Tests for integration (Unit, module, system
tests)
Documentation

Key System Change Risk Indicators
1. A structured system change methodology is not in
place.
2. A software change request procedure is not used.
3. Change requests are not reviewed/prioritized by a
representative group.
4. Feasibility studies are not performed when
appropriate.
5. Alternative software change designs are not
considered.
Key System Change Risk Indicators
6. Separate development, test, and production
libraries are not used.
7. Security and controls implications are not
considered.
8. Integration issues are not taken into account.
9. Testing is inadequately conducted.
10. Application changes are poorly documented.
Implementation Strategies
Purchased software needs testing.
Strategy must be chosen that best fits the
situation.
Consider risks of business interruption,
costs, time, ability of legacy system to
function.
Implementation Strategies
Parallel Implementation
New and Old system process side by side with
live data
Problems can be identified and corrected
Least risky
Heavy resource use:
Time to input, process, and create reports on two
systems
Time for reconciliation of output
Hardware requirements to run two systems

Implementation Strategies
Big-Bang Implementation
The old system is discontinued and the new
one becomes live the next instant.
Resources are not tied up running the old
system.
Staff is focused on success of new system.
New system failure could interrupt business
processes.
Implementation Strategies
Partial Implementation
Phase-in strategy starts one application of a
system at a time
Problems are resolved before the next
application begins.
Minimizes risk of business interruption.
May take a long time to implement entire new
system.
Implementation Strategies
Focused Implementation
Implements system first with small user groups
(office, departments, divisions, locations, etc.)
Group would use one of the previous
strategies.
Problems would be identified & resolved
before larger groups begin.
Could take a long time for full implementation
to be completed
Formal Implementation Plans
Process should be handled as a project
Organize tasks into Work Breakdown
Structure
Develop a formal change management
policy
Change Management
Establish an open line of communication
among all affected parties.
Develop thorough training and educational
programs.
Allow all affected parties to provide
instrumental input into the implementation
process as it unfolds.

Final Testing
Move object code from development library
to the test library
Test built-in security and control features
Effectiveness observed, tested and approved
by qualified overseers
Test interface programs
Key Implementation Risk Indicators
1. Alternative implementation strategies are not
considered:
a) Parallel
b) Big-Bang
c) Partial
d) Focused
2. Formal implementation plans are not followed.
3. All affected parties are not involved.
4. Implementation teams are uncoordinated.
Key Implementation Risk Indicators

5. Implementation processes are rushed.
6. Change management procedures are not
developed.
7. System users are inadequately trained.
8. Security and control issues are slighted.
9. Final testing is insufficient.
10. Post-implementation reviews are not conducted.