Chapter 4

Information
Technology
Development
Risks
Developing Strategic Plans
▸ Serves as primary guideline for allocating
resources.
▸ Keeps the organization headed in a profitable
direction.
▸ Begins with a vision.

2
Developing Strategic Plans
STRATEGIC PLANNING – is one of the most important
responsibilities of management, as this process serves
as the primary guideline for allocating scarce resources
throughout the firm and keeping the organization headed
in a profitable direction.

3
Strategic Planning Components
1. Vision
2. Mission
3. Objectives
4. Strategy
5. Policies

4
Strategic Planning Components

Mission Objectives Strategy Policies

Mission Objectives Strategy Policies

5
Developing Strategic Plans
▸ Strategic planning begins with a vision, or an image of
the future.
▸ The vision is translated into mission, which serves as the
guiding light for developing a set of objectives.
▸ Objectives, in turn, help shape the articulation of a formal
strategy.
▸ Finally, the strategy is used to develop a set of policies.

6
Developing Strategic Plans
VISION – represent what “might be” , based on a set of goals
and objectives the organization would like to achieve.
OBJECTIVES – serve as the foundation for setting an explicit
IT strategy, which details how the IT function will achieve
its objectives through its organizational structure,
relationship with others, and IT configuration.
POLICIES – are specific strategies which are designed to
enact the realization of the strategy.

7
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 organization’s overall
goals.

8
Example:
Ben & Jerry’s Mission Statement
Ben & Jerry’s 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.

9
Example:
Ben & Jerry’s Mission Statement
▸ 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 community—
local, national, and international.

10
Ben & Jerry’s 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 company’s three-part mission statement—comprised of
product, economic and social components.

11
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.
12
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 Company’s information system is fully integrated
on an entity-wide basis, as well as listen and respond to external
constituents to ensure that the Company’s business processes and
related information technology infrastructure meet the ever-
changing needs of the broader community of information
consumers.
13
 Important Policy Areas for IT Functions
1. Planning Policies
a. Responsibility (who is involved with planning?)
b. Timing (when does planning take place?)
c. Process (how should planning be conducted?)
d. Deliverables (what planning documents are
produced?)
e. Priorities (what are the most to least critical
planning issues?)
14
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 firm’s 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?)
15
Important Policy Areas for IT Functions
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?)

16
Important Policy Areas for IT Functions
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?)

17
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?)
18
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?)
19
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?)
20
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?)
21
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?)
22
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?)

23
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?)
24
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

25
Key Planning Risk Indicators: “Red Flags”
for IT Auditors
The following are planning risks indicators, should trigger red
flags for the IT auditor.
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 concluded.
5. Plans and goals are not communicated.

26
Key Planning Risk Indicators: “Red Flags”
for IT Auditors
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. Management’s information needs are not met.

27
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.

28
Professional Guidance
As suggested by CobiT, the IT function should:
1. Develop a strategic IT plan.
2. Articulate the information architecture
3. Find an optimal fit between IT and the company’s
strategy
4. Design the IT function to match the company's’ need.
5. Maximize the IT investment.

29
Professional Guidance
As suggested by CobiT, the IT function should:
6. Communicate IT policies to the user community.
7. Manage IT workforce.
8. Comply with external regulations, laws, and contracts.
9. Conduct IT risk assessment.
10. Maintain a high-quality systems development process.
11. Incorporate sound project management techniques.

30
Important Policy Areas for IT Function
IT FUNCTION SCORECARD - the balanced scorecard used
to plan and monitor the performance of the IT function.
USER SATISFACTION – customer satisfaction perspective of
the balanced scorecard which could be assessed by
periodically surveying user’s attitude.
OPERATIONAL PERFORMANCE – third balanced scorecard
perspective. Measured using indicators such as number
of security breaches, number of backlogged requests,
and percentage of downtime.

31
Balanced Scorecard
▸ Concept introduced in 1996 by Kaplan & Norton

▸ Scorecard measures financial and non-financial

performances

32
Kaplan’s Balanced Scorecard
“While
FINANCIAL and SOCIAL COST VALUE and BENEFIT
Goals Measures Targets Initiatives
achieving our Goals Targets Initiatives
“To achieve our Measur
vision, how
vision, what es
shall we
minimize cost values and
and maximize benefits must
profit?” we create?”

CUSTOMER and CONSTITUENTS INTERNAL BUSINESS PROCESS

“To achieve our Goals Measures Targets Initiatives “To satisfy our Goals Measures Targets Initiatives
vision, how must
customers and
Mission and customers and
the public, what
constituents view
our words and Vision business
processes must
actions?” we excel at?”

LEARNING and GROWTH

“To achieve Goals Measures Targets Initiatives
our vision,
how will we
sustain our
ability to
change and
improve?”

33
4 Perspectives of Scorecard
1. Financial
Non-financial indicators:
2. Customer satisfaction
3. Internal processes
4. Organizational Learning and Growth

34
Three Layered Structure
▸ 3-Layered Structure was devised for each of the 4
perspectives:
1. Mission
2. Objectives
3. Measures

35
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.

36
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.
37
IT Function Scorecard
▸ Use the balanced scorecard to plan & monitor IT
performance:

Customer
User Satisfaction
Satisfaction =

▸ Examples: Surveys of user attitudes for ease of use,

system reliability, and perceptions about the IT staff.
38
IT Function Scorecard
▸ Use the balanced scorecard to plan & monitor IT
performance:

Internal Operational
Process = Performance

▸ Examples: Number of security breaches, number of

backlogged requests, % of downtime.
39
IT Function Scorecard
▸ Use the balanced scorecard to plan & monitor IT
performance:

Learning and Adaptability and

Growth = Scalability

▸ Examples: Resources expended on developing interfaces,

ease of integrating new technology, and ability to keep
pace with organization’s IT growth. 40
IT Function Scorecard
Organizational User
Contribution Satisfaction

IT Function
Strategy

Operational Adaptability &

Performance Scalability

41
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.
42
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.

43
 Generic Project Life Cycle
Planning Scheduling Monitoring Controlling Closing
Boundary
Conditions

Scope
Parameters Parameters Parameters Time
Cost

Project Deliverable Deliverable Project

Resources Activity Activity Activity
1 2 4 Outcome

Activity Activity Activity

Resources Resources Resources
Parameters

Deliverable Deliverable

Activity Activity
Resources 3

Beginning End
44
Managing Development Projects
5 Phases of Project Life Cycle
1. PLANNING – involves setting time, scope, and cost parameters
for the entire project.
2. MANAGING – to schedule the specific sequencing and timing
of each activity and associated resources.
3. MONITORING – using benchmarks, milestones, and
deliverables to track progress.
4. CONTROLLING – concerns the development of specific actions
aimed at keeping a project moving forward.
5. CLOSING – obtaining client acceptance, release and evaluation.

45
Project Life Cycle Phase One
1. Plan the Project
▹ Set the Time, Cost & Scope
▹ Identify resources
▹ Articulate outcome
▹ Work with specialists
▹ Determine the WBS – Work Breakdown
Structure

46
Project Life Cycle Phase Two
2. Schedule the Project
▹ Create Timetable for each activity.
a. Gantt charts
b. Critical Path Analysis
c. Critical Math Method
d. Microsoft Project

47
Project Life Cycle Phase Three
3. 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.

48
Project Life Cycle Phase Four
4. Controlling
▹ Keep project moving
▹ Adjust to unexpected issues
▹ Continually adjust the plan

49
Project Life Cycle Phase Four
5. Closing the Project
▹ Obtain client acceptance in writing
▹ Release and evaluate project personnel
▹ Identify & reassign remaining project assets
▹ Evaluations of project
▹ Chronicle project history

50
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.

51
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.

52
Acquiring Software
▸ IT auditor should determine if the new application would
fit into the company’s 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.

53
Selection Process
▸ Assign a project manager
▹ Must know the needs of users & include them in
decisions
▸ Identify alternatives and compare:
Ease of use Internal controls
Functionality Integration with existing systems

Reporting Future scalability

Documentation Performance
Security features Cost

54
Total Cost of Software
▸ Price of acquisition
▸ User training
▸ Multiple licenses
▸ Service and support
▸ Future upgrades
▸ Software modifications

55
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.
56
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.

57
Developing Software Applications
▸ Information Systems Development Proposal – formal
documentation of requested project.

▸ Steering Committee reviews each proposal.

▸ Feasibility Group studies potential projects.

58
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?
59
Feasibility Study
▸ 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

60
Additional Systems Development Issues
BUSINESS PROCESS ANALYSIS – an integral part of the
planning phase of project management entails
conducting a thorough business process analysis before
starting any technical development work.
▹ 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.
61
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.

62
Development, Test and Production
Libraries
DEVELOPMENT, TESTING AND PRODUCTION – when
technical activities begin, the project team should
execute such task in a secured area of the computer
called development library.
Types of Library
1. Production library
2. Lest library
3. Development library

63
Development, Test and Production
Libraries
Development Test Production
Library Library Library

No Data Test Data Live Data

Secure Handoff Secure Handoff
Development Test Production
Source Code Object Code Object Code

Programmers Programmers Users

Only & Users Only

64
Additional Systems Development Issues
SECURITY AND CONTROLS
▹ Project team must plan security & control features
in development stage.
▹ Prevents patching program code later.
▹ Ultimate goal is to design as many automated
features as possible to optimize system reliability.

65
Additional Systems Development Issues
CONVERSIONS AND INTERFACES
▹ Conversion: Put existing data in correct format for
the new system
■ Scrub the data
■ Correct errors and omissions before it goes into
the new system
▹ Interfaces: Bridge the developed application to
related external applications
■ Be able to pass data back & forth.
66
Additional Systems Development Issues
IMPLEMENTATION TESTING
▸ Three Phases of Testing before going live:
1. Unit Testing: Tests in isolation for simple tasks
2. String or Module Testing: Test related programs
that are joined & handle multiple tasks.
3. System Testing: Test related modules that join the
entire application.
4. Stress Testing: Test final product under extreme
conditions.
67
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

68
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

69
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

70
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

71
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)

72
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

73
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.

74
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.

75
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.

76
Implementing Software Applications
Types of Implementation:

1. Parallel implementation
2. Big-bang implementation
3. Partial implementation
4. Focused implementation

77
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
78
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.

79
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.
80
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
81
Implementation Strategies
▸ Process should be handled as a project
▸ Organize tasks into Work Breakdown Structure
▸ Develop a formal change management policy

82
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.

83
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

84
Final Conversion
▸ Run programs that convert live data from old to new format
▹ Use archived data up to several days prior
▹ Fix data until programs work successfully
▸ Convert last days of data
▸ After successful conversion, move into the production library:
▹ Application object code
▹ Converted data
▹ Interface object code

85
Application is Live!
▸ Team still needs to work with users!
▹ Answer questions
▹ Fix Problems
▹ Monitor performance
▹ Performance Tuning
▹ User Acceptance
▸ Prepare a Post-implementation report

86
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.

87
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.

88
Thank you for listening!
Team Presentation Send your questions
to our facebook
messenger group
chats

Lecture materials will

be available through
Google Classroom

Jharam Tolentino, CPA, MBA Michael Sison, CPA, MBA

Program Head, Lecturer, College of Accountancy,
College of Accountancy University of Luzon
Study hard and aim
University of Luzon to be the best!