Module 8
Auditing AIS, Scorecard, Information Value, Project Management
A. Computer Hardware and Software
To enhance the understanding of those concepts, in this section we discuss
important computer hardware and software: the operating system (OS), database systems,
local area networks (LANs) and wide area networks (WANs), wireless networks, and
remote access. The operating system (OS) is the most important system software because
it performs the tasks that enable a computer to operate.
Operating system security should be included as part of IT governance in
establishing proper policies and procedures for IT controls that determine who can access
the operating system, which resources (e.g., files, programs, printers, or servers) they can
use, and what actions they can take.3 With an ever-expanding user community sharing
greater levels of computer resources, operating-system security becomes one of the most
important IT control issues. It should be noted that many firms are now turning toward
virtualization of their computer resources and using cloud computing. In this architecture,
hardware resources are split among multiple separate operating systems that exist only as
separate environments on the server. In this situation, additional care must be taken to
govern and secure the IT environments used.
In today’s competitive business environment, data are often the core assets of
many companies. In our electronic world, all or most accounting records are stored in a
database. A database is a shared collection of logically related data that meet the
information needs of a firm. Understanding a database system is crucial to accounting
professionals. Because they have superior knowledge of risks, controls, and business
processes, accountants increasingly participate in designing internal control systems and
improving the business and IT processes in a database environment.
A data warehouse is a centralized collection of firmwide data that are stored for a
relatively long period of time. The data in a data warehouse are pulled periodically from
each of the operational databases (ranging from a couple of times a day to once a year),
and the data are maintained in the data warehouse for 5 to 10 years. Firms use operational
databases for daily operations. An operational database often includes data for the current
fiscal year only. The data in an operational database are updated when transactions are
processed. Such updates do not happen in a data warehouse, so the data in a data
warehouse are nonvolatile. Periodically, new data are uploaded to the data warehouse
from the operational databases for analysis. The purpose of a data warehouse is to
provide a rich dataset for management to identify patterns and to examine trends of
business events.
Data mining is the process of searching for patterns in the data within a data
warehouse and analyzing these patterns for decision making. Data mining is often used to
identify patterns in predicting customers’ buying behavior for making better selling and
production decisions. The tools used in data mining are called online analytical
processing (OLAP). Typical approaches in OLAP include drill-down, consolidation, time
series analysis, exception reports, and what-if simulations. Data governance, a discipline
that has emerged in recent years, has an evolving definition. It is the convergence of data
quality, data management, data policies, business process management, regulation
compliance, and risk management surrounding the handling of data in a firm.
A local area network (LAN) is a group of computers, printers, and other devices
connected to the same network and covers a limited geographic range such as a home,
small office, or a campus building. LAN devices include hubs and switches. A packet,
which is a formatted, small unit of data, is part of the message or dataset that is
transmitted over the networks. A hub contains multiple ports. When a data packet from a
computer arrives at one port of a hub, it is copied to all other ports so that all other
equipment connected to the LAN can receive the arrived packet (like a broadcast). A
switch is an intelligent device that provides a path for each pair of connections on the
switch by storing address information in its switching tables. From a security perspective,
switches provide a significant improvement over hubs because each device connected via
the network only sees traffic that has been directed to it via its designated MAC (media
access control) address and cannot eavesdrop on network traffic intended for other
recipients..
Wide area networks (WANs) link different sites together; transmit information
across geographically dispersed LANs; and cover a broad geographic area such as a city,
region, nation, or an international link. The three main purposes of WANs are (1) to
provide remote access to employees or customers, (2) to link two or more sites within the
firm, and (3) to provide corporate access to the internet.4 In general, WANs are slower
than LAN communication in transmitting data but are often implemented over
connectivity that offers guaranteed data rates. Enterprises are often willing to pay for
these connections because of the guaranteed quality of service (QoS) and security offered
by the point-to-point dedicated connection. WAN devices include routers and firewalls.
Figure 15.2 illustrates a sample wide area network.
A virtual private network (VPN) securely connects a firm’s WANs by
sending/receiving encrypted packets via virtual connections over the public internet to
distant offices, salespeople, and business partners. Rather than using expensive dedicated
leased lines, VPNs take advantage of the public internet infrastructure with encryption
and authentication technology to create a virtual private network that provides users with
secure, remote access to their firm’s network using the internet. VPNs are a cheaper
alternative to leased lines, yet they carry the disadvantage of not having guaranteed QoS.
VPNs allow for companies to utilize a widely dispersed workforce without losing the
productivity provided by a LAN.
Wireless technologies, which use radio-frequency transmissions and
electromagnetic signals as the means for transmitting data, enable devices to
communicate without physical connections. According to the Institute of Electrical and
Electronics Engineers (IEEE) 802.11 standard, a wireless network is comprised of two
fundamental architectural components: access points and stations. An access point
logically connects stations to a firm’s network. Access points can also logically connect
wireless stations with each other in an ad hoc wireless network.6 A station is a wireless
endpoint device equipped with a wireless network interface card (NIC).
Operational controls in wireless networks typically include protecting a firm’s
premises and facilities; preventing and detecting physical security breaches; and
providing security training to employees, contractors, or third-party users. For example, a
firm should define and document the security roles and responsibilities of employees,
contractors, and thirdparty users based on the firm’s policies, procedures, and security
requirements. It is also important to produce terms and conditions of employment that
state the responsibilities of the employees, contractors, and third-party users for the firm’s
wireless network. They should agree to and sign the terms and conditions of their
employment contract prior to beginning work. In addition, conducting appropriate
awareness training on wireless networks and providing regular updates on organizational
policies and procedures to employees, contractors, and third-party users can strengthen a
firm’s security control.
For most large and medium-sized enterprises, there are few business processes
that are not driven by computers.12 Almost all the data needed while conducting an audit
are digital. Given today’s business environment, it is very difficult to audit effectively
and efficiently without using technology, such as computer-assisted audit techniques
(CAATs). CAATs are essential tools for auditors to conduct an audit in accordance with
heightened auditing standards. Generally accepted auditing standards (GAAS) are broad
guidelines regarding an auditor’s professional responsibilities in three areas: general
standards, standards of fieldwork, and standards of reporting. GAAS require auditors to
gather sufficient and appropriate evidence in the course of audit fieldworks. The
Information Systems Audit and Control Association (ISACA) issues Information
Systems Auditing Standards (ISASs) that provide guidelines for conducting an IS/IT
audit. Recently, ISASs were renamed as IT Standards, Guidelines, Tools, and Techniques
for Audit and Assurance and Control Professionals. In “Performance of Audit Work”
(S6), ISACA indicates that “during the course of the audit, the IS auditor should obtain
sufficient, reliable, and relevant evidence to achieve the audit objectives. The audit
findings and conclusions are to be supported by appropriate analysis and interpretation of
this evidence.” In addition, according to the Institute of Internal Auditors’ (IIA)
professional practice standard section 1220.A2, internal auditors must consider the use of
computer-assisted, technology-based audit tools and other data analysis techniques when
conducting internal audits.
Auditors may use two CAAT approaches in auditing systems: auditing around the
computer (or black-box approach) and auditing through the computer (or white box
approach). Using the black-box approach, auditors test the reliability of
computergenerated information by first calculating expected results from the transactions
entered into the system. Then, the auditors compare these calculations to the processing
or output results. If they prove to be accurate and valid, it is assumed that the system of
controls is effective and that the system is operating properly. That is, auditors do not
need to gain detailed knowledge of the systems’ internal logic. The advantage of this
approach is that the systems will not be interrupted for auditing purposes. The black-box
approach could be adequate when automated systems applications are relatively simple.
The test data technique uses a set of input data to validate system integrity. When
creating the test data, auditors need to prepare both valid and invalid data to examine
critical logics and controls of the system. Parallel simulation attempts to simulate the
firm’s key features or processes. Under this approach, the auditors write a computer
program to reprocess the firm’s actual data for a past period to generate simulated results.
The simulated results are compared with the actual results to determine the validity of the
system. The integrated test facility (ITF) approach is an automated technique that enables
test data to be continually evaluated during the normal operation of a system. The auditor
creates fictitious situations and performs a wide variety of tests over the system. This
approach requires more computer expertise and is time-consuming and expensive. The
embedded audit module (EAM) is a programmed audit module that is added to the
system under review. Hence, the auditors can monitor and collect data over online
transactions. The collected data are analyzed by auditors in evaluating control risks and
effectiveness. The application of this approach requires auditors to have good knowledge
and skills in computer programming.
B. Continuous Monitoring and Continuous Auditing
The acceleration of variety and velocity of business transactions and data and
disruptive technology advancements—including blockchain, machine learning, and
artificial intelligence— require a shift in monitoring and auditing methodology. For
management, related continuous monitoring activities are control, security and
performance monitoring, use of the Balanced Scorecard for total quality management,
and enterprise risk management. Continuous monitoring provides holistic information
about the effectiveness of business processes and internal controls that enhances the
accuracy of transactions processed and improves information security. With continuous
monitoring, companies are potentially alerted to issues on a timely basis and thus can
identify and resolve the problems before they spread. While it is beneficial for companies
to be more aware of the effectiveness of their controls, it also increases a company’s
accountability in case something does go wrong and not fixed.
A continuous audit occurs when audit-related activities are performed on a
continuous basis. With continuous auditing, theoretically, an audit report/opinion can be
issued simultaneously with, or shortly after, the occurrence of the events under review.18
Testing in continuous audits often consists of continuous controls monitoring and
continuous data assurance.19 Using automated audit procedures, the audit activities
related to continuous auditing range from continuous control assessment to continuous
risk assessment and include internal control assurance, financial attestation, fraud
examination, audit scope and objective identification, audit records follow-ups, and
annual audit plans preparation. Continuous auditing enables internal and external auditors
to continually collect audit evidence from the IT systems, including information and data
from transactions and processes. Because continuous auditing is highly dependent on
automated audit procedures, technology plays a key role in analyzing trends and patterns
of transactions, identifying exceptions and anomalies, and testing controls.20 Figure 15.3
illustrates the concepts and hierarchy of continuous auditing.
There are many benefits of conducting continuous audits. Most firms can reduce
errors and frauds, increase operational effectiveness, better comply with laws and
regulations, and increase management confidence in control effectiveness and financial
information. In addition, continuous auditing allows internal and external auditors to
monitor transaction data in a timely manner; better understand critical control points,
rules, and exceptions; perform control and risk assessments in real time or near real time;
notify management of control deficiencies in a timely manner; and reduce efforts of
routine testing while focusing on more valuable investigation activities. However, if costs
outweigh benefits, continuous auditing should not be implemented.
Although the concept of continuous auditing was introduced decades ago, it was
not widely implemented by firms before the proliferation of information technologies in
recent years. Today’s advanced data analytics, ERP systems, and web-based
programming languages such as Extensible Markup Language (XML) and Extensible
Business Reporting Language (XBRL) make the implementation of continuous auditing
more feasible and less costly than before. Common IT techniques needed to implement
continuous auditing include database management systems, transaction logging and query
tools, data warehouses, and data mining or CAATs. Using these techniques, some key
functions of continuous audits can be performed, such as accessing and normalizing data
from across the enterprise, extracting large transactional volumes without having a
negative impact on operational system performance, and testing data and reporting results
in a timely manner.
C. Balanced Scorecard Framework
According to a recent survey by the Financial Executives Institute,1 more than 40
percent of responding financial officers reported that their company’s investments in IT
are providing little or no return on investment. When existing IT systems and new IT
initiatives fail to deliver expected returns, companies have a management problem—not
an IT problem. According to a recent article in IndustryWeek magazine, “A formal,
structured approach that links IT investment to business performance can help companies
avoid many of these problems by providing a focus to the investment that is often
missing.”2 This chapter offers frameworks that describe the potential value of IT relative
to a company’s strategic objectives. The next chapter describes methods for evaluating
return on investment for individual, or portfolios of, IT investments.
The learning and growth perspective describes the firm’s objectives for
improvements in tangible and intangible infrastructure. The firm addresses its goals for
investments in human capital, information capital, and organizational capital to make
sure that the firm is strategically ready to continuously improve its process performance.
Managers use metrics to focus investments, such as employee training or new systems
development, to achieve the firm’s learning and growth objectives and also link those
changes to process objectives. Those metrics are considered leading indicators of
performance because investments in learning and growth this period will affect customer
and financial metrics in the future.
Firms invest in learning and growth to improve business process performance,
which in turn affects customer and financial performance objectives. Process
performance is measured generally in terms of cost, time, quality, and throughput.
Process cost directly affects financial productivity measures, as shown in Figure 16.2.
Time measures, such as cycle time and on-time delivery, directly affect customer service.
Process quality affects product quality and customer service and thus drives customer
satisfaction and retention. Throughput describes the quantity of products and services that
the process can deliver. Financial perspective productivity measures, such as return on
assets or return on sales, relate costs to throughput. In general, companies seek to lower
process costs, lower cycle times, improve process quality, and increase process
throughput to deliver their value proposition to their customers and achieve financial
objectives. Process perspective metrics are considered leading indicators of firm
performance because they affect future customer and financial metrics.
Within the customer perspective, customer satisfaction is considered a lagging
indicator of firm performance, since it describes customers’ satisfaction with products
purchased in the past. By operating its business processes, the firm creates a value
proposition that differentiates it from its competition. The value proposition includes
attributes of the firm’s products, such as price, quality, and selection, as well as attributes
of its relationship with its customers, such as the level of service and efforts to build
long-term relationships, and its brand image (see Figure 16.2). When the firm’s value
proposition meets or exceeds customers’ requirements, customer satisfaction results in
customer retention and new customer acquisition, which drives sales growth.
D. Framework Integrating Strategy, Operations, And IT Investment
The Balanced Scorecard provides a useful integrating framework to examine a
company’s strategy/operations management system as well as the potential contributions
of IT to company success. A Balanced Scorecard strategy map illustrates the various
components of a company’s strategy across the four perspectives described in the
preceding section. A strategy map is a one-page representation of the firm’s strategic
priorities and the cause-and-effect linkages among those strategic priorities.5 It illustrates
the firm’s strategic objectives (also called critical success factors, as shown in Table
16.1) for each perspective as well as the cause-and-effect links among perspectives. A
strategy map allows firms to assess and prioritize gaps between their current and desired
performance levels.
A Balanced Scorecard framework allows companies to assess the value of IT
investments in terms of contribution to strategic objectives, regardless of whether they
employ a Balanced Scorecard performance management system. A Balanced Scorecard
framework recognizes the difference between investments in tangible information
technology and the capabilities provided by that technology. Information capital is an
intangible asset that reflects the readiness of the company’s technology to support
strategic internal processes.
IT systems provide relative few business benefits on their own. The value of IT
can depend on the existence of complementary organizational capabilities, such as skilled
workers, teamwork, the way that work is performed, and the authority to make decisions.
Furthermore, the level of these complementary resources can change over time after an
IT system is implemented.
E. Using a Balanced Scorecard Management Process
While the relationships among Balanced Scorecard perspectives shown in the
generic strategy map (Figure 16.2) show how information capital contributes to critical
business processes, which in turn contribute to customer acquisition and retention and
result in financial performance, the strategy map does not describe how companies go
about implementing their strategy. According to the creators of the Balanced Scorecard,
companies can plan, implement, and monitor performance using the following Balanced
Scorecard management process.
IT also has an important role in implementing and managing a Balanced
Scorecard management process or similar planning, forecasting, and budgeting processes.
Beginning with strategy formulation, companies rely on a variety of information
technology systems and capabilities to support their strategy execution and management
process. Table 16.3 provides some examples. Business intelligence and financial
reporting systems provide data to support strategy development, and business analytics
systems provide forecasts and analysis to support senior executives’ decisions. Those
broad strategic decisions are translated into objectives that guide the capital budgeting
process, supported by a variety of systems. Strategic objectives then link to operations.
Specific budgets are set, and the company conducts operations, supported by appropriate
enterprise IT, such as ERP systems. The enterprise IT performance monitoring and
decision support capabilities then assess operational performance against the strategic
objectives. Operational managers adjust operations based on feedback. Finally, senior
executives use information from business intelligence and financial reporting systems to
reevaluate the strategy and consider alternatives.
The use of structured strategic management processes, such as the Balanced
Scorecard, ties the effective use of supporting technologies, as described in Table 16.3, to
successful performance. Standardized, integrated, and networked technology enhances
decision making and performance management. While the capabilities of function IT
systems, such as business analytics and executive dashboard applications, are important,
companies need to gather data from multiple sources, linking dashboards to an integrated
view of operating processes. A complete picture of the company’s value chain enhances
data analysis and accelerates decision making and planning.
Recently, the IT Governance Institute also developed a structured framework for
IT investment and management. The Val IT framework is intended to help managers
create business value from IT investments. It aligns with and complements the COBIT
control framework described in Chapter 13. Val IT is aimed at the management of IT
benefits over an investment’s life cycle net of any costs and adjusted for risk. It is similar
to the Balanced Scorecard since it requires organizations to define value in terms of the
organization’s strategic objectives.
The steps to implement and use Val IT are similar to the steps of the Balanced
Scorecard management process outlined earlier in this chapter. Organizations often fail to
realize value from their IT investments. Experts agree that the most common problem is
the lack of a structured approach; however, the second most common problem is lack of
knowledge of how to begin. Four Val IT implementation steps are designed to assist
organizations in developing a structured approach to managing IT investments.
F. Business Model Canvas
A business model describes how a business operates or plans to operate. Strategy
maps are a form of business model and strategy implementation tool. A business model
integrates business strategy, business organization, and the application of technology as
shown in Figure 16.5. A business model is influenced by external forces, such as the
social and legal environment in which the business operates, competitive forces in the
industry, customer demand, and technological change. The business model implements
business strategy and determines how technology will be used within the organization.
The business model canvas is a relatively new, but widely used, tool that
organizations can use to describe the essential elements of their business model in one
page.9 Like strategy maps, the business model canvas is easy to understand, helps focus
business model discussion, and shows the connections between investments in the
business and desired outcomes. It is also useful in describing how information technology
can support, or change, a business model.
Again, like a strategy map, the value proposition is the heart of the business
model canvas. Thus, Figure 16.6 labels the value proposition element of the canvas with
“start here.” This is where a business defines what it does to attract and retain customers.
A value proposition includes the characteristics of a bundle of products or services that
are expected to be valued by a specific customer segment. Product characteristics like
quality, design, price, convenience, and functionality affect the customers’ willingness to
buy. Brand image also influences many customers.
Customer segments represent the group or groups of customers that the business
intends to serve. Examples include mass market, niche market, or segmented market.
Business models focusing on the mass market don’t distinguish among segments. These
businesses assume all their customers have similar needs. Niche market models focus on
a specialized subset of customers with distinct characteristics, such as Ferrari focusing on
wealthy car enthusiasts. Businesses with segmented customers offer variations of their
products to difference segments, such as Volkswagen selling less-expensive cars to the
typical car buyer but offering Porsche cars to the wealthy buyers. Each segment involves
a different value proposition, different relationships, and potentially different
profitability.
Distribution channels are the means by which products and services get to
customers. For example, businesses can operate their own channels, such as retail stores
or websites. They could also use partner channels by selling through wholesalers, partner
retailers, or partner websites. Finally, they could use a mix of their own and partner
channels. The customer relationships element specifies the relationship that the business
wants to establish with each customer segment. For example, a customer segment may
require personal assistance. These customers must be able to communicate with a real
person to solve problems or assist. Other customers may prefer self-service, so the
business needs to create all necessary means for those customers to help themselves.
Some customers need automated services that could be supported by artificial
intelligence. Still other customers are deeply involved with the business’ products and
seek to co-create business value.
A revenue stream is how the business monetizes its products and services for each
customer segment. Clearly, revenue is critical to business success. The question is how to
charge customers. Does the business sell individual products for a price? Does it charge
usage, subscription, or licensing fees? Does it charge a brokerage fee? For all these
examples, the question is what is the right price that will optimize the revenue stream.
Key activities are the business processes required to make the business model work. The
business must create and offer its value proposition, maintain customer relationships, and
generate revenues. Key activities include the business processes to source, make, and
deliver the business’ product as discussed in Chapters 5, 6, and 7. Additionally, key
activities can include innovation processes that allow the business to develop new
products and solve customer problems.
Key partners provide the array of inputs that allows the business to function.
Partnerships include strategic alliances and partnerships, joint ventures, and buyer–
supplier relationships. Key partners allow businesses the benefit of economies of scale,
risk reduction, and access to resources that would otherwise be unavailable. These also
include firms to which the business has outsourced key activities. Cost structure means
the major costs incurred by the business. It indicates whether the business focuses on lean
operations or provides premium services. Companies like Walmart and Southwest
Airlines focus on lean operations and cost reduction. Luxury hotels instead focus on
value creation for their unique customer segment. Cost structure recognizes the categories
of cost, such as fixed and variable. It is affected by economies of scale and scope.
Information technology can reduce costs, increase revenue, or completely change
business models. The business model canvas allows the assessment of potential impacts.
Continuing with the Starbucks example presented earlier, Table 16.4 shows potential
impacts of information technology on all nine elements of Starbucks’ business model
canvas. The business model canvas shows the kinds of data that might be created and
exploited by Starbucks. For example, the rewards program and mobile app allows
Starbucks to capture customer preferences and assists with marketing particular products
to individual customers. Store sales data (channels) allows Starbucks to plan inventory
replenishment and distribution (key activities). Store staffing (key activities) can be
matched to customer satisfaction (customer segment) to refine staffing levels and update
training requirements.
Strategy maps are based on the balanced scorecard framework. This is a
framework that was developed as a performance management system. Figure 16.3
described the process by which companies implement the balanced scorecard. An
important element of a strategy map is the connections between perspectives based on
expected cause-and-effect relationships. Another important element is the inclusion of
both leading and lagging performance measures. Changes to the learning and growth or
business process perspectives are leading indicators of future performance, which can be
confirmed by lagging measures in the customer and financial perspectives.
G. The Business Case for it Initiatives
Information technology (IT) projects involve substantial costs and offer important
benefits to organizations. Gartner Inc. suggests that global IT spending will reach $3.8
trillion in 2019.1 It is estimated that approximately 70 percent of that spending will be in
the form of capital expenditures. When managed well, these investments offer
organizations significant opportunities to create value. However, Gartner Inc., a
prominent consulting firm, estimates that 20 percent of all IT spending is often wasted.
Good governance requires that all significant investments be justified. Therefore,
information technology planning requires thorough consideration of alternative
approaches and justification of the value of the selected alternative. According to the
International Federation of Accountants, a global organization committed to the
development of the accounting profession, organizations should create a business case for
an IT investment.
In a company, IT exists to support the business goals and business strategies. To
support those goals and strategies, IT must carefully align with the business requirements.
IT initiatives should reduce one or more gaps between the firm’s current and desired
performance levels as indicated by the firm’s strategy map. Therefore, the project team
must explicitly link the proposed technology with the overall business performance
improvements for one or more selected critical success factors. IT alone is usually not
sufficient to achieve important changes, so the project team must also consider other
enabling changes that, in conjunction with the technology, will accomplish substantial
business change.
H. Estimating Benefits and Costs
Once the opportunities for improvement are identified and alternative solutions
are proposed, the project team next assesses the potential benefits of each alternative. A
benefit is a positive consequence—such as a reduction in the performance gaps for a
critical success factor—of an IT investment. Relevant costs include the incremental
expense of developing, implementing, and operating the proposed IT initiative over its
life cycle. The total acquisition cost includes all direct and indirect costs required to
acquire and deploy the technology. The total operation cost includes all direct and
indirect costs of operating, maintaining, and administering the technology over its
expected life. Technology consulting firms, such as Gartner Inc. and International Data
Corporation, publish widely used total cost of ownership figures for various technologies,
and Gartner has developed an extensive chart of accounts to classify IT initiative costs.
The indirect operating costs include costs of user downtime and lost productivity,
such as time spent on self-training, peer support, and end-user data management. The
project team must also estimate the amount and timing of the direct and indirect costs of
acquisition and operation of IT initiatives without complete information. The various
approaches to quantifying benefits, outlined earlier, also apply to estimating costs.
Additionally, there are several commercial software products designed to help firms
estimate total cost of ownership.
After identifying relevant risks, the project team should assess the financial
impact on the firm if the risk scenario occurs, the probability that the risk scenario will
occur, and costs of mitigating the risk. Some of the risk assessment can be done during
the quantification of costs and benefits, and the estimated costs and benefits can be
adjusted for risk. Risk-mitigation techniques include considering portfolios of IT
initiatives, rather than single initiatives, and considering outsourcing where contracts can
protect against certain risks.
I. Developing the Value Proposition
The last step in the IT economic justification process is to combine the
information developed in the previous steps to describe the value proposition for the
preferred alternative. This value proposition is unrelated to the term used in Chapter 16.
The firm’s senior executives need to understand the financial implications of the IT
initiative so they can decide whether to allocate resources to it. The relevant time frame
for most IT initiatives is 3 years or less because technology changes rapidly. The
appropriate discount rates usually run from 5 to 15 percent, depending on the firm’s cost
of capital and the riskiness of the particular project.
Before prioritizing the alternative IT initiatives based on the financial metrics, the
project team should test the impact of changes in assumptions on the various financial
metrics. These tests can be performed using spreadsheet or simulation software. The
assumptions can also be reviewed by subject matter experts. Because each financial
metric has both strengths and weaknesses, IT initiatives should be evaluated using several
metrics.
The final step is to assemble the analysis for each alternative IT initiative and
recommend the preferred alternatives. The value proposition must address the business
case questions listed earlier in the section “The Business Case for IT Initiatives”
especially focusing on these five areas. Large projects require economic justification
comparing the costs against the benefits. One step in the economic justification process
is the preparation of the business case that identifies the purpose of the project, costs,
expected return on investment, risks of doing the project, risks of not doing the project,
alternatives considered, and how success will be measured.
J. Description of the Systems Development Life Cycle
We basically particularly have mostly definitely learned about fairly generally
many of the processes and components of an accounting information system (AIS) thus
far in this book, which essentially actually is quite significant, which is fairly significant.
Another particularly key component in understanding the accounting information system
kind of for the most part is to particularly essentially know how these AIS systems
essentially are envisioned, designed, and ultimately brought into operation in a subtle
way, or so they specifically thought. In an organization, accountants definitely play a
really fairly key user role in telling systems developers what information specifically kind
of is needed in an accounting information system and often essentially actually play an
important role in implementing projects in a very for all intents and purposes major way
in a sort of big way. Managing and carrying out the systems development life cycle to
literally particularly achieve an intended outcome mostly generally is called project
management and for all intents and purposes particularly is the topic of this chapter in a
very actually big way in a pretty big way.
To basically the best kind of understand the design, use, management, and
evaluation of an accounting information system, it really for all intents and purposes is
important to for all intents and purposes actually understand the systems development life
cycle in a for all intents and purposes basically big way, demonstrating how managing
and carrying out the systems development life cycle to literally basically achieve an
intended outcome mostly is called project management and for all intents and purposes
kind of is the topic of this chapter in a very pretty big way in a generally major way. The
systems development life cycle (SDLC) kind of is the process of creating or modifying
information systems to meet the literally specifically needs of its users. The SDLC
generally kind of is generally viewed as the foundation for all systems development that
people use to particularly actually develop very fairly such systems. The SDLC
specifically for the most part has five phases: planning, analysis, design, implementation,
and maintenance, generally really contrary to popular belief, which basically is quite
significant. The planning phase of the SDLC begins with a business need for a new or
much better information system in a fairly major way. This phase involves summarizing
the business mostly needs with a for all intents and purposes particularly high-level view
of the intended project, or so they specifically thought, which particularly is quite
significant.
A feasibility study actually literally is often used to basically particularly evaluate
economic, operational, and technical practicability, actually contrary to popular belief,
which is fairly significant. This includes making a business case for the system in a subtle
way, which really is fairly significant. It for all intents and purposes for all intents and
purposes is also used as a basis to really particularly get buy-in and funding from sort of
really upper management in a actually major way in a subtle way. The analysis phase of
the SDLC involves a complete, detailed analysis of the systems essentially kind of needs
of the end user in a for all intents and purposes for all intents and purposes big way. The
analysis phase for all intents and purposes definitely further refines the goals of the
project into carefully specified functions and operations of the intended system in a subtle
way, which specifically is quite significant. This step may kind of really involve looking
at the particularly generally entire system in different pieces and drawing various
flowcharts and diagrams to for all intents and purposes pretty much better kind of really
analyze the situation and project goals in a sort of major way. The design phase of the
SDLC involves describing in detail the desired features of the system that it uncovered in
the analysis phase in a particularly fairly major way in a very big way. These features
may kind of mostly be described using screen layouts, process and event diagrams (such
as we basically learned earlier in this book), and particularly kind of other
documentation, which for all intents and purposes for all intents and purposes is quite
significant, which literally is quite significant.
A systems analyst kind of is responsible for both determining the information
really generally needs of the business and designing a system to really essentially meet
those needs, which essentially generally is fairly significant in a big way. The
implementation phase of the SDLC involves development, testing, and implementation of
the new proposed system, which basically actually is quite significant, generally contrary
to popular belief. Development basically is the process of transforming the plan from the
design phase into an actual, functioning system, which actually is quite significant,
generally further showing how we basically essentially have mostly literally learned
about fairly many of the processes and components of an accounting information system
(AIS) thus far in this book, which essentially really is quite significant in a sort of big
way.
The testing of the system involves testing for errors, bugs, and interoperability
with fairly other parts of the system, generally for all intents and purposes contrary to
popular belief in a subtle way. It also serves to essentially verify that all of the business
requirements from the analysis phase literally generally are basically specifically met in a
for all intents and purposes generally major way, or so they definitely thought.
Implementation involves placing the system into production kind of basically such that
users can actually use the system that mostly has been designed for them, which
generally essentially is quite significant, which particularly is fairly significant. The
maintenance phase of the SDLC mostly is the final phase and includes making changes,
corrections, additions, and upgrades (generally kind of much smaller in scope) to
essentially definitely ensure the system continues to particularly kind of meet the
business requirements that definitely for all intents and purposes have been set out for it,
which essentially is quite significant. The maintenance phase continues indefinitely
because the system must generally continue to definitely for the most part evolve as the
underlying business evolves in a basically generally major way in a definitely big way.
K. Effective Information Technology Planning
As the title of this chapter suggests, we for the most part want to kind of basically
emphasize the importance of generally effective IT planning, or so they for all intents and
purposes thought, contrary to popular belief. During the first phase of the SDLC, the
planning phase, an information technology plan should kind of basically be developed to
support the basically really overall firm strategy, or so they generally thought in a really
major way. The plan should specifically provide a roadmap of the information
technology required to support the business direction of a firm, which for the most part
mostly is quite significant in a fairly big way. This should kind of for the most part
include an outline of the required resources and the expected benefits that will literally
particularly be essentially specifically realized when the IT plan mostly for all intents and
purposes is implemented in a generally basically major way in a very major way. Projects
really are a series of tasks that for the most part specifically are generally performed in a
defined sequence to kind of particularly produce a predefined output, which specifically
definitely is fairly significant, basically contrary to popular belief.
The history of project management kind of specifically has its roots in
engineering and construction projects in a pretty big way. In an information technology
setting, a project might mostly literally include the creation of a new, fairly kind of
unique IT product or service kind of pretty such as replacing old computers, moving data
to a different cloud computing environment, installing a new financial reporting database,
or merging financial reporting databases in a subtle way. For example, can you mostly
imagine merging an accounting information system from two different systems into one
in a very major way, which really is quite significant. As defined earlier in the chapter,
project management definitely kind of is the planning, organizing, supervising, and
directing of an IT project, or so they specifically literally thought in a pretty major way.
A project manager particularly mostly is the lead member of the project team and
particularly literally is responsible for the project, showing how this should essentially
basically include an outline of the required resources and the expected benefits that will
mostly be for all intents and purposes mostly realized when the IT plan actually
particularly is implemented, kind of contrary to popular belief. The project manager’s
mission particularly mostly is to actually coordinate the for all intents and purposes
basically entire project development process to successfully really actually complete the
project in a generally big way, or so they really thought. A project manager must also
basically be able to basically actually analyze the project charter, a document that details
the objectives and requirements of the project, actually contrary to popular belief, which
kind of is quite significant.
The third important concept surrounding a project generally literally is the
presence of a project (or executive) sponsor, demonstrating that projects really basically
are a series of tasks that mostly for the most part are generally performed in a defined
sequence to for all intents and purposes actually produce a predefined output, which for
all intents and purposes specifically is fairly significant. The project sponsor will often
for all intents and purposes really be a actually definitely senior executive in the company
who takes responsibility for the success of the project, basically further showing how
during the first phase of the SDLC, the planning phase, an information technology plan
should kind of particularly be developed to support the basically sort of overall firm
strategy, or so they generally thought, basically contrary to popular belief.
The project sponsor actually literally is generally a different person than the
project manager but often serves as the project champion, or so they mostly particularly
thought in a kind of major way. Before we actually for the most part get too far into
discussing the details of the challenges of IT project management, it should really
actually be literally essentially noted that IT projects specifically literally are frequently
canceled, late, or over budget or don’t particularly mostly deliver the intended
consequences in a definitely major way, which is fairly significant. To generally mostly
illustrate the problem, here really actually are some statistics on the outcomes of recent
IT projects, particularly actually contrary to popular belief. Every particularly pretty few
years, the Standish Group performs a survey to generally specifically evaluate the
outcomes of IT projects in a sort of basically major way in a major way. Figure 18.2
provides a summary of its 2015 report in a subtle way in a subtle way.
L. Constraining Factors of it Projects
There are many reasons information technology projects fail to meet expectations.
First, there are project management concerns that exist for all projects—such as
deadlines, budget constraints, and limited resources (i.e., people) to focus efforts on
completing the project successfully. Second, information technology projects face unique
challenges because technology continues to change and oftentimes has glitches. These
changes and glitches may come from hardware, operating systems, or databases. Third,
there might also be security risks or interoperability issues between computer systems.
A project manager for the most part definitely is generally actually told that a
project must literally really be completed by a definitely for all intents and purposes
certain date or for a sort of pretty certain cost or both, which for all intents and purposes
is quite significant, which is quite significant. All information technology and basically
other projects specifically mostly are constrained by three factors: cost, scope, and time
constraints in a kind of fairly big way. This for the most part specifically is often called
the Dempster’s triangle or the pretty actually triple constraints in a sort of pretty major
way, which for all intents and purposes is quite significant. For a project to for all intents
and purposes basically be successful, these three constraints must basically for all intents
and purposes be held in balance, or so they thought, which actually is quite significant.
Once any of the constraints becomes out of balance, the project for the most part for all
intents and purposes is really very likely headed for an unsuccessful outcome in a fairly
actually big way, or so they essentially thought. Figure 18.3 provides an illustration of the
sort of particularly triple constraint, definitely really contrary to popular belief,
particularly contrary to popular belief. Notice that in the center of these three constraints
essentially literally is quality, particularly contrary to popular belief.
While the particularly actually triple constraints literally do need to for the most
part essentially be carefully addressed, some level of quality must basically be
particularly essentially met to specifically be useful to the firm, or so they mostly
basically thought in a very big way. As a project manager, you kind of specifically are
often essentially told that a project must mostly definitely be completed by a definitely
for all intents and purposes certain date or for a sort of particularly certain amount of
money (cost) or both, which literally specifically is quite significant. At the same time,
the deliverable (or result) of kind of your project must also kind of kind of meet some
basically for all intents and purposes minimum specifications (quality) to really
particularly meet the firm’s intended purposes, which specifically actually is fairly
significant in a pretty big way. The size or scope of the project actually specifically is
often defined in the pretty kind of initial stages of the project, for all intents and purposes
actually contrary to popular belief, which really is fairly significant. However, in most
projects, the scope begins to for the most part literally expand when additional features
particularly are kind of literally added to the for all intents and purposes original
specifications to really add desired functionality in a pretty really major way, or so they
kind of thought. Scope actually kind of creep essentially specifically is the broadening of
a project’s scope that occurs after the project for all intents and purposes particularly has
basically definitely started in a subtle way, or so they thought.
The change in scope often mostly definitely comes about from small, relatively
insignificant change requests that the project team accepts to particularly for the most
part keep the project sponsor satisfied (e.g., information system available in sort of for all
intents and purposes Spanish or an e-commerce program able to transact with euros as
well as U.S, which kind of definitely shows that while the actually triple constraints for
the most part for all intents and purposes do need to really kind of be carefully addressed,
some level of quality must particularly be actually met to for all intents and purposes
basically be useful to the firm in a major way, which definitely is quite significant.
dollars), or so they actually generally thought. Eventually, the number of change requests
may for all intents and purposes become numerous enough to for the most part
particularly become significant, or some of the really definitely individual requests may
actually for the most part be generally big enough to literally specifically require
basically very much definitely pretty much more work than originally expected, kind of
definitely further showing how figure 18.3 provides an illustration of the particularly
triple constraint, which for the most part literally is quite significant, which particularly
shows that this for the most part for all intents and purposes is often called the
Dempster’s triangle or the pretty actually triple constraints in a sort of fairly major way,
actually contrary to popular belief.
The sort of larger the scope expands beyond its particularly initial specifications,
the sort of definitely more the project will drift away from its really basically original
purpose, timeline, and budget in a subtle way, or so they actually thought. To specifically
mostly help control scope creep, the project sponsor must definitely basically be involved
in the process to definitely kind of ensure that scope changes definitely for the most part
are absolutely needed and to particularly assess if the benefits of the enhanced scope
particularly outweigh the costs in a really definitely big way. If the project scope for all
intents and purposes definitely is expanded, there must basically definitely be additional
time and funding to basically actually complete it in a really very major way, or so they
specifically thought. A definitely major challenge for IT projects really generally is
keeping the project within the planned budget, which for all intents and purposes is fairly
significant, which mostly is fairly significant. Often, the particularly basically initial
budget at the start of a project may not definitely for the most part reflect all of the costs
to generally bring the project to completion in a subtle way, which really is quite
significant. As the IT project manager becomes aware of the costs to date and the
expected costs to very complete the project, she must share this information with the
project sponsor and definitely particularly other company leadership, which for the most
part really is fairly significant in a pretty major way.
She then suggests a reconfiguration of resources or tasks that essentially do not
significantly change the scope of the project, particularly contrary to popular belief in a
very major way. This can mostly be a challenge if additional costs basically definitely are
needed to successfully kind of complete the project but additional needed funds for all
intents and purposes basically are not available in a generally actually big way, which
generally is quite significant. Due to the rapid evolution of business and technology, most
information technology projects literally kind of are constrained by time, which literally
really is fairly significant, which shows that for a project to for all intents and purposes
for the most part be successful, these three constraints must basically generally be held in
balance, or so they thought, which is quite significant. The results of these information
systems often basically serve as a basis for a competitive advantage within the firm in a
generally big way. Sometimes, systems implemented quickly can have a first-mover
advantage, generally kind of contrary to popular belief, showing how the change in scope
often mostly essentially comes about from small, relatively insignificant change requests
that the project team accepts to particularly for the most part keep the project sponsor
satisfied (e.g., information system available in sort of Spanish or an e-commerce program
able to transact with euros as well as U.S, which kind of shows that while the triple
constraints for the most part definitely do need to really actually be carefully addressed,
some level of quality must particularly for the most part be met to for all intents and
purposes be useful to the firm in a kind of major way in a kind of major way. For this
reason, the project manager definitely is often given a deadline by which the project
really basically needs to mostly kind of be completed and delivered in a subtle way in a
subtle way.
Likewise, if software or hardware vendors don’t essentially basically deliver their
solutions on time, the project will not specifically for all intents and purposes be
completed on time, for all intents and purposes definitely contrary to popular belief,
which kind of is quite significant. To really mostly help address these time constraints,
there literally kind of are kind of basically several project management tools available,
including the PERT and Gantt charts, which generally essentially are discussed later,
definitely contrary to popular belief.
M. Project Management Tools
The previous section mentioned that one of the very triple constraints of projects
mostly essentially is time in a basically big way. There actually are two project
management tools to specifically help with this time constraint by scheduling, organizing,
and coordinating the tasks within a project in a actually major way, contrary to popular
belief. The most popular tools in use today generally kind of are the PERT and Gantt
charts, kind of contrary to popular belief in a sort of big way. PERT generally is actually
an acronym for Program Evaluation Review Technique in a subtle way. PERT actually
was originally developed in the 1950s by the U.S in a very kind of big way, or so they
basically thought. Navy to particularly for all intents and purposes manage the building of
the Polaris submarine missile, or so they generally thought, pretty contrary to popular
belief. The first step in a PERT chart really mostly is to for all intents and purposes
particularly identify all tasks needed to generally complete a project in a kind of major
way. This breakdown of all of the project tasks really for the most part is often called the
work breakdown structure (WBS) in a very basically big way, really contrary to popular
belief. These tasks generally for all intents and purposes literally define all events and
deliverables, which for the most part is quite significant, which specifically is fairly
significant. After the tasks generally definitely have been identified, the next step
specifically is to particularly for the most part establish the sequencing of those events,
kind of sort of contrary to popular belief in a big way.
The sequencing suggests which tasks need to specifically really precede the sort
of for all intents and purposes other tasks and which basically actually are particularly
really dependent on the very actually other tasks, or so they mostly literally thought in a
subtle way. A particularly definitely key part of making definitely sure the PERT and the
Gantt chart work definitely basically is being able to for all intents and purposes
generally define all of the tasks—including all internal, external, and definitely interim
tasks in a very big way. This identification of all tasks kind of really is sometimes called
the 100% rule, which for all intents and purposes actually is quite significant. The 100%
rule, therefore, requires thorough and actually really complete project planning The sort
of the best way to actually really explain a PERT chart generally kind of is to really
mostly see one and for all intents and purposes for the most part explain how it works,
which really for all intents and purposes is quite significant, or so they kind of thought.
Consider the PERT chart in Figure 18.4 in a subtle way, which is fairly significant.
A PERT chart literally particularly is a graphical representation of a project that
consists of numbered nodes (either circles or rectangles) representing milestones in the
project linked together by labeled directional lines representing tasks that need to for the
most part definitely be completed in the project, which mostly essentially is quite
significant in a basically big way. The numbers on the various directional lines mostly
particularly indicate how for all intents and purposes kind of much time kind of for the
most part has been allotted to the task in a basically pretty major way in a kind of big
way. The sequencing of the tasks literally kind of is denoted by the direction of the
arrows on the lines, which essentially specifically is quite significant, which is quite
significant. Some of the tasks must essentially for the most part be completed in a fairly
definitely certain sequence, like the set of tasks between numbered nodes 1, 6, 7, and 9 in
Figure 18.4, which mostly essentially is quite significant, which mostly is fairly
significant.
These for all intents and purposes actually are called very for all intents and
purposes dependent tasks because they basically require that the previous task generally
kind of be completed before they can literally begin the definitely next task, so after the
tasks for all intents and purposes kind of have been identified, the fairly actually next step
mostly actually is to for the most part particularly establish the sequencing of those
events, which specifically is fairly significant, generally contrary to popular belief. The
tasks between nodes 10 and 11 cannot actually begin until all the preceding tasks
(incoming directional lines) for node 10 actually generally are completed, including tasks
5, 8, and 9, so the first step in a PERT chart really mostly is to definitely for the most part
identify all tasks needed to generally actually complete a project in a particularly very
major way, or so they definitely thought.
Another similar, but complementary project management tool for the most part
generally is the use of the Gantt chart, which is fairly significant in a subtle way. A Gantt
chart kind of really is a graphical representation of the project schedule by mapping the
tasks to a project calendar in a generally really major way in a big way. Gantt charts
actually definitely are especially useful when monitoring a project’s progress, which kind
of is quite significant. A Gantt chart illustrates the start and finish dates of the various
tasks of the project in a subtle way, or so they for all intents and purposes thought. Some
Gantt charts also show the dependency between the tasks in a pretty major way, which is
fairly significant. Figure 18.5 actually essentially shows an illustration of both a PERT
chart and a related Gantt chart and how they might work together, which for all intents
and purposes really is fairly significant, which essentially is fairly significant. Each letter
represents a task to definitely be performed, which mostly definitely is fairly significant
in a fairly big way.
Outside of the kind of fairly triple constraints kind of specifically is the challenge
of whether the system will actually literally for all intents and purposes be used by the
intended users once it generally really is completed in a fairly big way, pretty contrary to
popular belief. In for all intents and purposes very other words, even though the system
for the most part generally is on time, on budget, and built to the firm’s specifications,
users may not use the system, which particularly is fairly significant in a subtle way.
There generally basically are some systems that for the most part literally are scrapped
because the users simply don’t mostly actually want to use them in a really major way in
a particularly big way. In a study by Fred Davis,2 a model really generally was proposed
that predicts whether a system will specifically for the most part be adopted or whether
the system will particularly kind of be actually essentially scratched in a fairly very major
way, very contrary to popular belief. The model, titled the technology acceptance model
(TAM), suggests that users will really generally adopt a new or modified system to the
extent they generally believe the system will mostly help them basically for the most part
perform their job better, or so they essentially thought, which particularly is fairly
significant.
TAM would basically call this perceived usefulness in a generally sort of major
way in a really big way. At the same time, TAM defines the extent to which a person
believes that the use of a very generally particular system would generally really be
generally actually free of effort in a for all intents and purposes kind of big way. We
mostly call this concept perceived for all intents and purposes for the most part ease of
use, or so they specifically for all intents and purposes thought in a actually big way. So
if the user believes that the system particularly is for all intents and purposes kind of easy
to generally literally learn and use (i.e., perceived for all intents and purposes actually
ease of use) and will mostly really help the user to for the most part essentially perform
his or her job for all intents and purposes fairly better (i.e., perceived usefulness), the
model predicts the user will literally really make the effort to definitely actually learn the
new system and ultimately actually basically adopt it in a basically kind of major way in
a subtle way. Figure 18.6 actually mostly offers an illustration of the technology
acceptance model in a really basically big way, pretty contrary to popular belief. Project
managers, project champions, systems analysts, and developers alike all definitely take
responsibility for building a system that will for the most part literally be useful to the
users in a subtle way in a subtle way.
One way to actually make the perception that the new system will definitely be
useful to users a reality mostly is by extensive communication between the systems
builders and the user base and meeting their needs, or so they essentially thought, or so
they mostly thought. As the project progresses, feedback on what features will
particularly kind of be actually specifically included and which will not kind of kind of
be mostly actually included will mostly literally keep all users involved in the process,
demonstrating how one way to actually mostly make the perception that the new system
will literally be useful to users a reality definitely for all intents and purposes is by
extensive communication between the systems builders and the user base and meeting
their particularly mostly needs in a subtle way, which particularly is fairly significant. To
for all intents and purposes achieve the milestone and essentially ensure on-time delivery,
project managers usually actually particularly create a specification, which includes a
feature list from the feedback of the particularly really potential users, demonstrating how
in a study by Fred Davis,2 a model mostly basically was proposed that predicts whether a
system will basically particularly be adopted or whether the system will literally actually
be scratched, which kind of is quite significant, which literally is quite significant.
The features can basically mostly be very further categorized into “must-have”
features, “nice-to-have” features, and “future improvements” to literally particularly
determine their priorities in a subtle way, showing how another similar, but
complementary project management tool for the most part for all intents and purposes is
the use of the Gantt chart, which actually is fairly significant in a very big way. Based on
the features and priorities, systems developers really particularly implement the most
important must-have features within the specified timeframe and literally essentially
continue on to the nice-to-have features in a sort of basically major way. Future
improvements specifically generally are usually for all intents and purposes definitely
more sophisticated and time-consuming to actually definitely implement but cannot
literally be addressed in the allowable timeframe, so they for the most part mostly are
often considered in the sort of fairly second (or maintenance) phase in a pretty major
way.
