Introduction to IT Governance

The IT Governance Institute defines IT governance as structure of relationships and processes to

direct and control the enterprise in order to achieve the enterprise’s goals by adding value while
balancing risk versus return over IT and its processes. IT governance provides the structure that links IT
processes, IT resources, and information to enterprise strategies and objectives. A summary of this
definition is that the board of directors and top‐level executive managers must take responsibility to
ensure that the organization has processes that align IT systems to the strategies and objectives of the
organization.
Management must focus on the following activities:
• Aligning IT strategy with the business strategy
• Cascading strategy and goals down into the enterprise
• Providing organizational structures that facilitate the implementation of strategy and goals
• Insisting that an IT control framework be adopted and implemented
• Measuring IT’s performance
Three popular models of an IT control framework:
1. Information Systems Audit and Control Association (ISACA) control objectives for IT (COBIT)
2. The International Organization for Standardization (ISO) 27002, Code of Practice for Information
Security Management
3. The Information Technology Infrastructure Library (ITIL)
Top executive management and lower‐level managers all must work toward the same goal of
ensuring IT systems and strategy align with the organization’s strategic goals. To match company
strategy to IT systems, the company should have an IT governance committee and a formal process to
select, design, and implement IT systems. The IT governance committee is a group of senior managers
selected to oversee the strategic management of IT. The formal process that many organizations use to
select, design, and implement IT systems is the system development life cycle, or SDLC.

An Overview of the SDLC

The systems development life cycle (SDLC) is a systematic process to manage the acquisition,
design, implementation, and use of IT systems.
 The phases of the SDLC are briefly defined as:
1. Systems planning is the evaluation of long‐term, strategic objectives and the prioritization of IT
systems in order to assist the organization in achieving its objectives. Systems planning also
involves the planning and continuous oversight of the design, implementation, and use of those
IT systems.
2. Systems analysis is a study of the current system to determine the strengths and weaknesses
and the user needs of that system. Analysis requires the collection of data about the system and
the careful scrutiny of that data to determine areas of the system that can be improved.
3. Systems design is the creation of the system that meets user needs and that incorporates the
improvements identified by the systems analysis phase.
4. Systems implementation is the set of steps undertaken to program, test, and activate the IT
system as designed in the system design phase.
5. Operation and maintenance is the regular, ongoing functioning of the IT system and the
processes to fix smaller problems, or “bugs,” in the IT system. During operation, management
should request and receive ongoing reports about the performance of the IT system.

The process map in Exhibit 5‐2 shows these various phases of the SDLC. Conceptual design is the
process of matching alternative system models with the needs identified in the system analysis phase.
Evaluation and selection is the process of assessing the feasibility and fit of each of these alternative
conceptual approaches and selecting the one that best meets the organization’s needs. The best system
may be either software that can be purchased, or a system designed and developed in‐house. If
software is to be purchased, the company must undergo a set of steps called software selection to select
the best software for its needs. When systems are to be developed in‐house, the company must
undertake steps to design the details of that system. Detailed design is the process of designing the
outputs, inputs, user interfaces, databases, manual procedures, security and controls, and
documentation of the new system.
Elements of the Systems Planning Phase of the SDLC

Systems planning is a managerial function of the IT governance committee. The IT governance

committee must constantly monitor the IT system through feedback about network utilization, security
breaches, and reports on the operation of the system. This constant monitoring allows the IT
governance committee to determine whether the current system meets organizational needs. To
prioritize these projects, the IT governance committee should consider two broad aspects: (1) the
assessment of IT systems and their match to strategic organizational objectives, and (2) the feasibility of
each of the requested modifications or upgrades. In addition, the IT governance committee must plan
and manage the design, implementation, and use of those IT systems. Exhibit 5‐3 details the systems
planning process.

The Match of IT Systems to Strategic Objectives

Evaluating the match of proposed IT changes to strategic objectives will allow the IT governance
committee to begin prioritizing the desired changes. Top management has the authority to allocate
resources and time to these projects that will modify or upgrade IT systems.

Feasibility Study
There are four feasibility aspects that should be considered—remember them by the acronym
TOES:
1. Technical feasibility—assessment of the realistic possibility that technology exists to meet the needs
identified in the proposed change to the IT system.
2. Operational feasibility—assessment of the realistic possibility that current employees will be able to
operate the proposed IT system. If the operation will require new training of employees, this assessment
should evaluate the feasibility of providing training to existing employees.
3. Economic feasibility—assessment of the costs and benefits associated with the proposed IT system. Is
it realistic to conclude that the benefits of the proposed IT system outweigh the costs?
4. Schedule feasibility—assessment of the realistic possibility that the proposed IT system can be
implemented within a reasonable time.

Planning and Oversight of the Proposed Changes

The committee should do several things to initiate the next phases of the SDLC:
1. Formally announce the project they have chosen to undertake.
2. Assign the project team that will begin the next phase, the systems analysis.
3. Budget the funds necessary to complete the SDLC.
4. Continue oversight and management of the project team and proposed IT changes as the remaining
SDLC phases occur.

Elements of the Systems Analysis Phase of the SDLC

Preliminary Investigation
The purpose of the preliminary investigation is to determine whether the problem or deficiency
in the current system really exists.

System Survey: The Study of the Current System

The systems survey is a detailed study of the current system to identify weaknesses to improve
upon and strengths to be maintained. A systems survey requires collecting data about the current
system, including the following:
• Inputs—sources of data
• Outputs—the uses of information from processing and outputs such as checks, reports, or forms
• Processes—the individual steps undertaken to process transactions, including both manual and
computerized processes
• Controls—the internal controls within the processing system
• Data storage—how and where data is stored, and the size of the data storage
• Transaction volumes—number of transactions per day or per hour
• Errors—number of transaction processing errors

Data collection involves observation, documentation review, interviews, and questionnaires.

Observation is watching the steps that employees take as they process transactions in the system. The
purpose of the observation is to enable the project team to gain an understanding of the processing
steps within the system. Documentation review is the detailed examination of documentation that
exists about the system to gain an understanding of the system under study.

Determination of User Requirements

Interviews and questionnaires are data collection methods that solicit feedback from users of
the system. Interviews are the face‐to‐face, verbal questioning of users to determine facts or beliefs
about the system. Questionnaires are a written, rather than an oral, form of questioning users to
determine facts or beliefs about the system.

Analysis of the System Survey

The analysis phase is the critical‐thinking stage of the systems analysis. The purpose is to
question the current approaches used in the system and to think about better ways to carry out the
steps and processes in the system. In many cases, the analysis phase and the attempt to create
improvements may lead to business process reengineering (BPR). BPR has been defined as
“fundamental rethinking and radical redesign of business processes to bring about dramatic
improvements” in performance.
IT and BPR have a mutually enhancing relationship. IT capabilities should support the business
processes, and any business process should be designed to match the capabilities that the IT system can
provide. BPR should leverage the capabilities of IT to improve the efficiency of processes. As discussed
earlier, Anheuser Busch uses extensive IT systems to improve the forecasting of customer buying
patterns.

Systems Analysis Report

The last step in the systems analysis phase is to prepare a systems analysis report for delivery to
the IT governance committee, which will inform the IT governance committee of the results of the
systems survey, user needs determination, and BPR. The report will make recommendations to the IT
governance committee regarding the continuation of the project.

Elements of the Systems Design Phase of the SDLC

The Purchase of Software
When the project team has reached the design phase, user needs and system requirements
have previously been determined in the systems analysis phase. Therefore, the project team is ready to
solicit proposals from different software vendors for accounting systems that satisfy the identified user
needs and meet the system requirements. The process to solicit proposals is called a request for
proposal, or RFP. There are many things that the project team and IT governance committee should
consider when evaluating each proposal, such as the following:
1. The price of the software or software modules
2. The match of system and user needs to the features of the software
3. The technical, operational, economic, and schedule feasibility
4. Technical support provided by the vendor
5. Reputation and reliability of the vendor
6. Usability and user friendliness of the software
7. Testimonials from other customers who use the software.
In‐House Design
Hiring a Consultant As discussed, while it is not necessary to hire a consulting firm, many
organizations find that the special expertise of consulting firms is most beneficial in the design and
implementation of accounting system software. Such firms have a broad range of expertise, assisting
many different types of organizations with many different types of software systems.

Conceptual Design
The next step is the conceptual design phase, which involves identifying the alternative
conceptual design approaches to systems that will meet the needs identified in the system analysis
phase. This step could be viewed as a sort of “brainstorming” to generate the different conceptual
approaches in a system design that will meet the identified needs.

Evaluation and Selection

Evaluation and selection is the process of assessing the feasibility and fit of each of the alternative
conceptual approaches and selecting the one that best fits the organization’s needs. The feasibility
assessments in the study include the following:
1. Technical feasibility. The project team will assess the technical feasibility of each alternative
conceptual design.
2. Operational feasibility. The project team will assess the realism of the possibility of operating each
of the alternative designs.
3. Economic feasibility. The project team must estimate the costs and benefits of each alternative
design.
4. Schedule feasibility. For each alternative design, the project team must estimate the total amount of
time that will be required to implement the revised system.

Cloud Computing as a Conceptual Design

In addition to the risks and benefits mentioned here, there are other considerations related to
adopting or increasing cloud computing usage, such as:
1. The customer support provided by the cloud vendor. It is important to fully understand the level and
reliability of support provided by a cloud vendor.
2. The service level agreement (SLA) with the cloud provider. This contract should clearly specify the
vendor’s responsibilities, including the billing terms and expectations about allowable downtime.
3. The manner of monitoring cloud service usage. Since cloud computing is often a pay for service model
in which the client pays for the level of service used, it is important that the client is able to monitor
usage and reconcile billing with the actual service usage. As a simple analogy, you probably carefully
review your cell phone bill to make sure you were not charged for more services than you used.
Likewise, cloud computing clients must be able to track their usage of the cloud services and reconcile
their measure of services used to the billing provided by the cloud vendor.

Detailed Design
The end result of the evaluation and selection phase of the SDLC is that the best alternative
design is selected. Once the design has been selected, the details of that selection must be designed.
The purpose of the detailed design phase is to create the entire set of specifications necessary to build
and implement the system. The various parts of the system that must be designed are the outputs,
inputs, processes, data storage, and internal controls. Outputs of the system are reports and documents,
such as income statements, aged accounts receivable listings, inventory status reports, and sales by
product. Other outputs are documents or turn‐around documents. Inputs are the forms, documents,
screens, or electronic means used to put data into the accounting system.
The inputs must be designed to work efficiently and with as few errors as possible. Samples of
the different methods of data input are as follows:
1. Keying in data with a keyboard from data on a paper form. The person operating the keyboard must
enter data from a paper form into an input screen on the computer.
2. Magnetic ink character recognition (MICR) is used on checks and turn‐around documents such as the
portion of your credit card bill that you return. The computer system reads the magnetic ink to
determine information such as account number.
3. Electronic data interchange (EDI), in which standard business documents are transmitted
electronically.
4. Internet commerce, in which the customer enters customer and order data.
5. Bar code scanning, such as in the point‐of‐sale systems used by grocery and department stores.

Elements of the Systems Implementation Phase of the SDLC

As depicted in Exhibit 5‐7, some tasks can occur simultaneously. The employee training, program
testing, and documentation can all be undertaken at the same time.
Software Programming
Using the design specifications developed in the detailed design phase, the programming staff
would write the program code for the new or revised system. In the case of purchased software, the
programming staff would modify the program code as necessary to meet the design specifications.

Training Employees
As the programming is completed or nearing completion, employees should be trained to use
the new system. Depending on the extent of changes from the old system, employees may need training
in the use of new input screens, output reports, and processes.

Software Testing
As programmers complete the programming of the new system, the programs and the modules
that make up the programs must be tested. Software should never be implemented before it is tested;
otherwise, it can cause errors or problems in the accounting system and thereby result in erroneous
accounting data. The most common way to test software is to use test data, which is specially created
and entered into the software to ensure that the software works correctly.

Documenting the System

There are many kinds of documentation necessary to operate and maintain an accounting
system, including flowcharts, data flow diagrams, entity relationship diagrams, process maps, operator
manuals, and data dictionaries. The lack of up‐to‐date documentation makes it much more difficult for
new employees to understand the system and makes future revisions to the system more complicated.

Data Conversion
The file or database storage for the new system may be different from the storage format of the
old system. In most instances, a conversion program can be written or acquired that will convert the
data from the old to the new format. Accountants should oversee the data conversion process to make
sure that all accounting data is completely and correctly converted.

System Conversion
There are several different conversion methods to choose from: parallel conversion, direct
cutover conversion, phase‐in conversion, and pilot conversion. Parallel conversion is a conversion
method in which the old and new systems are operated simultaneously for a short time. Direct cutover
conversion means that on a chosen date the old system operation is terminated and all processing
begins on the new system. Phase‐in conversion is a method in which the system is broken into modules,
or parts, which are phased in incrementally and over a longer period. Pilot conversion is the system that
is operated in only one or a few subunits of the organization.

User Acceptance
User acceptance means that when the manager of the primary users of the system is satisfied
with the system, he will sign an acceptance agreement. The enforcement of user acceptance makes it
much more likely that project teams will seek user input and that the project team will work hard to
meet user needs.

Post‐Implementation Review
Post‐implementation review is a review of the feasibility assessments and other estimates made
during the process. The purpose of the review is to help the organization learn from any mistakes that
were made. The review does not correct any errors made, but it helps the company avoid those same
errors in the future.

Elements of the Operation and Maintenance Phase of the SDLC

After implementation, the company will operate and maintain the system for some length of
time. This part of the SDLC is the longest and most costly part, since it may last for several years. At
some point, the company will need to make major revisions or updates to the system, which will trigger
the SDLC to begin again to revise the system. During the ongoing operation, management should receive
regular reports regarding the performance of the IT system. The reports are necessary to monitor the
performance of IT and to enable management to determine whether IT is aligned with business strategy
and meets the objectives of the IT system. Some examples of these IT reports are the following:
• IT performance
• IT load usage and excess capacity
• Downtime of IT systems
• Maintenance hours on IT systems
• IT security and number of security breaches or problems
• IT customer satisfaction, from both internal and external customers. Internal customers are the
various users of IT systems within the organization.
These reports are an important part of IT governance, as they drive the continual monitoring of the IT
system.

The Critical Importance of IT Governance in Organization

Three major purposes are served by the continual and proper use of the IT governance
committee and the SDLC:
1. The strategic management process of the organization
2. The internal control structure of the organization
3. The fulfillment of ethical obligations

SDLC as Part of Strategic Management

An SDLC process serves as the mechanism to continually assess the fit of IT systems to long‐term
strategy and short‐run goals of the organization. Once the IT governance committee has identified which
types of IT systems are appropriate for the organization, the SDLC becomes the mechanism to properly
manage the development, acquisition, and implementation of IT systems.

SDLC as an Internal Control

The Trust Services Principles illustrate that the SDLC and an IT governance committee are
important parts of the IT system of an organization. Without the use of an IT governance committee and
the SDLC, the process of revising or updating systems can be chaotic and uncontrolled. An organization
would likely find that an uncontrolled approach results in poorly designed and documented systems. In
addition, systems that result from such a chaotic process would probably not meet user needs and
would not be likely to support the strategic objectives of the company.

Ethical Considerations Related to IT Governance

Managers, employees, and consultants all have obligations to act ethically while engaged in
changes to IT systems. Managers must ensure that proper IT systems are functioning to meet the
stewardship obligation they have for the assets entrusted to them. In addition, they must consider
confidentiality and the effects of employee displacement as changes occur. Employees have obligations
to provide honest feedback about IT systems and to not disclose confidential information. Consultants
have ethical obligations to bid and bill time fairly, to not oversell IT system modules, and to maintain
confidentiality.