IVP_A_R_TBuilding_and_ManagingSystems11_Building_Information

IVP A R TBuilding and ManagingSystems 11 Building Information Systems and

Managing Projects

12 Ethical and Social Issues in Information Systems

Part IV shows how to use the knowledge acquired in earlier chapters to analyze and design information system solutions to

business problems. This part answers questions such as these:

How can I develop a solution to an information system problem

that provides genuine business benefits? How can the firm adjust to

the changes introduced by the new system solution? What

alternative approaches are available for building system solutions?

What broader ethical and social issues should be addressed when

building and using information systems?

IS B

N 1-

25 6-

42 91

3- 9

S T U D E N T L E A R N I N G O B J E C T I V E S

After completing this chapter, you will be able to answer the following questions:

1. What are the core problem-solving steps for developing new information systems?

2. What are the alternative methods for building information systems?

3. What are the principal methodologies for modeling and designing systems?

4. How should information systems projects be selected and evaluated?

5. How should information systems projects be managed?

Building Information Systems and Managing

Projects11

378

IS B

N 1-256-42913-9

379

CHAPTER OUTLINE Chapter-Opening Case: A New Ordering System for

Girl Scout Cookies

11.1 Problem Solving and Systems Development

11.2 Alternative Systems-Building Approaches

11.3 Modeling and Designing Systems

11.4 Project Management

11.5 Hands-On MIS Projects

Business Problem-Solving Case: The U.S. Census Bureau Field Data Collection Project: Don’t Count on It

A NEW ORDERING SYSTEM FOR GIRL SCOUT COOKIES

Peanut Butter Petites, Caramel DeLites, Thin Mints—Girl Scout Cookies have been American favorites since the organization’s first cookie drive in 1917. The Girl Scouts have been so successful selling cookies that cookie sales are a major source of funding for this organization. The Girl Scouts sell so many cookies that collecting, counting, and organizing the annual avalanche of orders has become a tremendous challenge.

The Girl Scouts’ traditional cookie-ordering process depended on mountains of paperwork. During the peak sales period in January, each Girl Scout marked her sales on an individual order card and turned the card in to the troop leader when she was finished. The troop leader would transfer the information onto a five-part form and give this form to a community volunteer who tabulated the orders. From there, the orders data passed to a regional council headquarters, where they would be batched into final orders for the manufacturer, ABC Cookies. In addition to ordering, Girl Scout volunteers and troop members had to coordinate cookie deliveries, from the manufacturer to regional warehouses, to local drop-off sites, to each scout, and to the customers themselves.

IS B

N 1-

25 6-

42 91

3- 9

The Patriots’ Trail Girl Scout Council, representing 65 communities and 18,000 Girl Scouts in the greater Boston area, sold more than 1.6 million boxes of eight different cookie varieties in 2004 alone. According to its associate executive director Deborah Deacetis, the paperwork had become “overwhelming.” “It changed hands too many times. There was a lot of opportunity for error, because of all the added columns, multiple prices per box, and calculations that had to be made by different people, all on deadline.”

The Patriots’ Trail Council first looked into building a computerized system using Microsoft Access database management and application development tools. But this alternative would have cost $25,000 to develop and would have taken at least three to four months to get the system up and running. It was too time-consuming, complex, and expensive for the Girl Scouts. In addition to Microsoft Access software, the Girl Scouts would have to purchase a server to run the system, plus pay for networking and Web site maintenance services so the system could be made available on the Web.

After consulting with management consultants Dovetail Associates, the council selected Intuit’s QuickBase for Corporate Workgroups. QuickBase is a hosted Web-based software service for small businesses and corporate workgroups. It is especially well suited for building simple database applications very quickly and does not require a great deal of training to use. QuickBase is customizable and designed to collect, organize, and share data among teams in many different locations.

A Dovetail consultant created a working QuickBase prototype with some basic functions for the Girl Scouts within a few hours. It only took two months to build, test, and implement the entire system using this software. The cost for developing the entire system was a fraction of the Microsoft Access solution. The Girl Scouts do not have to pay for any hardware, software, or networking services because QuickBase runs everything for them on its servers. QuickBase costs $500 per month for organizations with 100 users and $1,500 per month for organizations with up to 500 users. It is very easy to use.

The QuickBase solution eliminates paperwork and calculation errors by providing a clear central source of data for the entire council and easy online entry of cookie orders over the Web. Troop leaders collect the Girl Scouts’ order cards and enter them directly into the QuickBase system using their home computers linked to the Web. With a few mouse clicks, the council office consolidates the unit totals and transmits the orders electronically to ABC Cookies.

In the past, the council relied on volunteers to handle their paperwork, dropping it off at the council office or mailing it in. “Now we have a way to actually watch the orders coming in,” Deacetis notes. As local orders come in, local section leaders can track the data in real time.

The Patriots’ Trail Girl Scout Council also uses the QuickBase system to manage the Cookie Cupboard warehouse, where volunteers pick up their cookie orders. Volunteers use the system to make reservations so that the warehouse can prepare the orders in advance, saving time and inventory management costs. The trucking companies that deliver cookie shipments now receive their instructions electronically through QuickBase so that they can create efficient delivery schedules.

Since its implementation, the QuickBase system has cut paperwork by more than 90 percent, reduced errors to 1 percent, and reduced the time spent by volunteers by 50 percent. The old system used to take two months to tally the orders and determine which Scouts should be rewarded for selling the most cookies. Now that time has been cut to 48 hours.

Sources: www.girlscoutseasternmass.org/cookies, accessed October 29, 2009 and “Girl Scouts Unite Behind Order Tracking,” Customer Relationship Management, May 2005.

The experience of the Patriots’ Trail Girl Scout Council illustrates some of the steps required to design and build new information systems. It also illustrates some of the benefits of a new system solution. The Girl Scouts had an outdated manual paper-based system for processing cookie orders that was excessively time-consuming and error ridden. The Girl Scouts tried several alternative solutions before opting for a new ordering system based on the QuickBase software service. In this chapter, we will examine the Girl Scouts’ search for a system solution as we describe each step of building a new information system using the problem-solving process.

380 Part IV: Building and Managing Systems IS

B N

1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 381

11.1 Problem Solving and Systems Development

We have already described the problem-solving process and how it helps us analyze and understand the role of information systems in business. This problem-solving process is especially valuable when we need to build new systems. A new information system is built as a solution to a problem or set of problems the organization perceives it is facing. The problem may be one in which managers and employees believe that the business is not performing as well as expected, or it may come from the realization that the organization should take advantage of new opportunities to perform more effectively.

Let’s apply this problem-solving process to system building. Figure 11-1 illustrates the four steps we would need to take: (1) define and understand the problem, (2) develop alternative solutions, (3) choose the best solution, and (4) implement the solution.

Figure 11-1 Developing an Information System Solution Developing an informa- tion system solution is based on the problem- solving process.

IS B

N 1-

25 6-

42 91

3- 9

382 Part IV: Building and Managing Systems

Before a problem can be solved, it first must be properly defined. Members of the organization must agree that a problem actually exists and that it is serious. The problem must be investigated so that it can be better understood. Next comes a period of devising alternative solutions, then one of evaluating each alternative and selecting the best solution. The final stage is one of implementing the solution, in which a detailed design for the solution is specified, translated into a physical system, tested, introduced to the organization, and further refined as it is used over time.

In the information systems world, we have a special name for these activities. Figure 11-1 shows that the first three problem-solving steps, where we identify the problem, gather information, devise alternative solutions, and make a decision about the best solution, are called systems analysis.

DEFINING AND UNDERSTANDING THE PROBLEM

Defining the problem may take some work because various members of the company may have different ideas about the nature of the problem and its severity. What caused the problem? Why is it still around? Why wasn’t it solved long ago? Systems analysts typically gather facts about existing systems and problems by examining documents, work papers, procedures, and system operations and by interviewing key users of the system.

Information systems problems in the business world typically result from a combination of people, organization, and technology factors. When identifying a key issue or problem, ask what kind of problem it is: Is it a people problem, an organizational problem, a technology problem, or a combination of these? What people, organizational, and technological factors contributed to the problem?

Once the problem has been defined and analyzed, it is possible to make some decisions about what should and can be done. What are the objectives of a solution to the problem? Is the firm’s objective to reduce costs, increase sales, or improve relationships with customers, suppliers, or employees? Do managers have sufficient information for decision making? What information is required to achieve these objectives?

At the most basic level, the information requirements of a new system identify who needs what information, where, when, and how. Requirements analysis carefully defines the objectives of the new or modified system and develops a detailed description of the functions that the new system must perform. A system designed around the wrong set of requirements will either have to be discarded because of poor performance or will need to undergo major modifications. Section 11.2 describes alternative approaches to eliciting requirements that help minimize this problem.

Let’s return to our opening case about the Girl Scouts. The problem here is that the Girl Scout ordering process is heavily manual and cannot support the large number of volunteers and cookie orders that must be coordinated. As a result, cookie ordering is extremely inefficient with high error rates and volunteers spending excessive time organizing orders and deliveries.

Organizationally, the Girl Scouts are a voluntary organization distributed across a large area, with cookie sales as the primary source of revenue. The Scouts rely on volunteers with little or no business or computer experience for sales and management of orders and deliveries. They have almost no financial resources and volunteers are strapped for time. The Girl Scout cookie-ordering process requires many steps and coordination of multiple groups and organizations—individual Girl Scouts, volunteers, the council office, the cookie manufacturing factory, trucking companies, and the Cookie Cupboard warehouse.

The objectives of a solution for the Girl Scouts would be to reduce the amount of time, effort, and errors in the cookie-ordering process. Information requirements for the solution include the ability to rapidly total and organize order transactions for transmittal to ABC Cookies; the ability to track orders by type of cookie, troop, and individual Girl Scout; the ability to schedule deliveries to the Cookie Cupboard; and the ability to schedule order pickups from the Cookie Cupboard.

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 383

DEVELOPING ALTERNATIVE SOLUTIONS

What alternative solutions are possible for achieving these objectives and meeting these information requirements? The systems analysis lays out the most likely paths to follow given the nature of the problem. Some possible solutions do not require an information system solution but instead call for an adjustment in management, additional training, or refinement of existing organizational procedures. Some, however, do require modifications to the firm’s existing information systems or an entirely new information system.

EVALUATING AND CHOOSING SOLUTIONS

The systems analysis includes a feasibility study to determine whether each proposed solution is feasible, or achievable, from a financial, technical, and organizational standpoint. The feasibility study establishes whether each alternative solution is a good investment, whether the technology needed for the system is available and can be handled by the firm’s information systems staff, and whether the organization is capable of accommodating the changes introduced by the system.

A written systems proposal report describes the costs and benefits, and advantages and disadvantages of each alternative solution. Which solution is best in a financial sense? Which works best for the organization? The systems analysis will detail the costs and benefits of each alternative and the changes that the organization will have to make to use the solution effectively. We provide a detailed discussion of how to determine the business value of systems and manage change in the following section. On the basis of this report, management will select what it believes is the best solution for the company.

The Patriots’ Trail Girl Scouts had three alternative solutions. One was to streamline existing processes, continuing to rely on manual procedures. However, given the large number of Girl Scouts and cookie orders, as well as relationships with manufacturers and shippers, redesigning and streamlining a manual ordering and delivery process would not have provided many benefits. The Girl Scouts needed an automated solution that accurately tracked thousands of order and delivery transactions, reduced paperwork, and created a central real-time source of sales data that could be accessed by council headquarters and individual volunteers.

A second alternative was to custom-build a cookie-ordering system using Microsoft Access. This alternative was considered too time-consuming, expensive, and technically challenging for the Girl Scouts. It required $25,000 in initial programming costs, plus the purchase of hardware and networking equipment to run the system and link it to the Internet, as well as trained staff to run and maintain the system.

The third alternative was to rapidly create a system using an application service provider. QuickBase provides templates and tools for creating simple database systems in very short periods, provides the hardware for running the application and Web site, and can be accessed by many different users over the Web. This solution does not require the Girl Scouts to purchase any hardware, software, or networking technology or to maintain any information system staff to support the system. This last alternative was the most feasible for the Girl Scouts.

IMPLEMENTING THE SOLUTION

The first step in implementing a system solution is to create detailed design specifications. Systems design shows how the chosen solution should be realized. The system design is the model or blueprint for an information system solution and consists of all the specifications that will deliver the functions identified during systems analysis. These specifications should address all of the technical, organization, and people components of the system solu- tion. Table 11.1 lists the types of specifications that would be produced during system design.

IS B

N 1-

25 6-

42 91

3- 9

384 Part IV: Building and Managing Systems

A Dovetail Associates consultant elicited information requirements and created a design for the new Girl Scout cookie system. Table 11.2 shows some of the design specifications for the new system.

Completing Implementation In the final steps of implementing a system solution, the following activities would be performed:

• Hardware selection and acquisition. System builders select appropriate hardware for the application. They would either purchase the necessary computers and networking hardware or lease them from a technology provider.

• Software development and programming. Software is custom programmed in-house or purchased from an external source, such as an outsourcing vendor, an application software package vendor, or an application service provider.

The Girl Scouts did not have to purchase additional hardware or software. QuickBase offers templates for generating simple database applications. Dovetail consultants used the QuickBase tools to rapidly create the software for the system. The system runs on QuickBase servers.

• Testing. The system is thoroughly tested to ensure it produces the right results. The testing process requires detailed testing of individual computer programs, called unit testing, as well as system testing, which tests the performance of the information system as a whole. Acceptance testing provides the final certification that the system is ready to be used in a production setting. Information systems tests are evaluated by users and reviewed by management. When all parties are satisfied that the new system meets their standards, the system is formally accepted for installation.

The systems development team works with users to devise a systematic test plan. The test plan includes all of the preparations for the series of tests we have just described.

Output

Input

User interface

Database

Processing

Manual procedures

Security and controls

Conversion

Training and documentation

Organizational changes

Medium and content Timing

Flow Data entry

Feedback and error handling

Logical data model Volume and speed requirements File and record specifications

Program logic and computations

What activities, who, when, how, and where

Access controls Input, processing, and output controls

Testing method Conversion strategy

Training modules and platforms Systems, user, and operations documentation

Process design Organizational structure changes

TABLE 11.1

System Design Specifications

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 385

Figure 11-2 shows a sample from a test plan that might have been used for the Girl Scout cookie system. The condition being tested is online access of an existing record for a specific Girl Scout troop.

• Training and documentation. End users and information system specialists require training so that they will be able to use the new system. Detailed documentation showing how the system works from both a technical and end-user standpoint must be prepared.

Output Online reports

Hard copy reports

Online queries

Order transactions for ABC Cookies

Delivery tickets for the trucking firm

Input Order data entry form

Troop data entry form

Girl Scout data entry form

Shipping/delivery data entry form

User interface Graphical Web interface

Database Database with cookie order file, delivery file,

troop contact file

Processing Calculate order totals by type of cookie and number of boxes

Track orders by troop and individual Girl Scout

Schedule pickups at the Cookie Cupboard

Update Girl Scout and troop data for address and member changes

Manual procedures Girl Scouts take orders with paper forms

Troop leaders collect order cards from Scouts and enter the order data online

Security and controls Online passwords

Control totals

Conversion Input Girl Scout and troop data

Transfer factory and delivery data

Test system

Training and documentation System guide for users

Online practice demonstration

Online training sessions

Training for ABC Cookies and trucking companies to accept data and instructions automatically from the Girl Scout system

Organizational changes Job design: Volunteers no longer have to tabulate orders

Process design: Take orders on manual cards but enter them online into the system

Schedule order pickups from the Cookie Cupboard online

TABLE 11.2

Design Specifications for the Girl Scout Cookie System

IS B

N 1-

25 6-

42 91

3- 9

The Girl Scout cookie system provides an online practice area for users to practice entering data into the system by following step-by-step instructions. Also available on the Web is a step-by-step instruction guide for the system that can be downloaded and printed as a hard-copy manual.

• Conversion is the process of changing from the old system to the new system. There are three main conversion strategies: the parallel strategy, the direct cutover strategy, and the phased approach strategy.

In a parallel strategy, both the old system and its potential replacement are run together for a time until everyone is assured that the new one functions correctly. The old system remains available as a backup in case of problems. The direct cutover strategy replaces the old system entirely with the new system on an appointed day, carrying the risk that there is no system to fall back on if problems arise. A phased approach introduces the system in stages (such as first introducing the modules for ordering Girl Scout cookies and then introducing the modules for transmitting orders and instructions to the cookie factory and shipper). • Production and maintenance. After the new system is installed and conversion is

complete, the system is said to be in production. During this stage, users and technical specialists review the solution to determine how well it has met its original objectives and to decide whether any revisions or modifications are in order. Changes in hardware, software, documentation, or procedures to a production system to correct errors, meet new requirements, or improve processing efficiency are termed maintenance.

The Girl Scouts continued to improve and refine their QuickBase cookie system. The system was made more efficient for users with slow Internet connections. Other recent enhancements include capabilities for paying for orders more rapidly, entering troop information and initial orders without waiting for a specified starting date, and receiving online confirmation for reservations to pick up orders from the Cookie Cupboard.

Managing the Change Developing a new information systems solution is not merely a matter of installing hardware and software. The business must also deal with the organizational changes that the new solution will bring about—new information, new business processes, and perhaps new reporting relationships and decision-making power. A very well-designed solution may not work unless it is introduced to the organization very carefully. The process of planning

386 Part IV: Building and Managing Systems

Figure 11-2 A Sample Test Plan for the Girl Scout Cookie System When developing a test plan, it is imperative to include the various conditions to be tested, the requirements for each condition tested, and the expected results. Test plans require input from both end users and information systems specialists.

IS B

N 1-256-42913-9

change in an organization so that it is implemented in an orderly and effective manner is so critical to the success or failure of information system solutions that we devote the next section to a detailed discussion of this topic.

To manage the transition from the old manual cookie-ordering processes to the new system, the Girl Scouts would have to inform troop leaders and volunteers about changes in cookie-ordering procedures, provide training, and provide resources for answering any questions that arose as parents and volunteers started using the system. They would need to work with ABC Cookies and their shippers on new procedures for transmitting and delivering orders.

11.2 Alternative Systems-Building Approaches

There are alternative methods for building systems using the basic problem-solving model we have just described. These alternative methods include the traditional systems lifecycle, prototyping, end-user development, application software packages, and outsourcing.

TRADITIONAL SYSTEMS DEVELOPMENT LIFECYCLE

The systems development lifecycle (SDLC) is the oldest method for building information systems. The lifecycle methodology is a phased approach to building a system, dividing systems development into a series of formal stages, as illustrated in Figure 11-3. Although systems builders can go back and forth among stages in the lifecycle, the systems lifecycle is predominantly a “waterfall” approach in which tasks in one stage are completed before work for the next stage begins.

This approach maintains a very formal division of labor between end users and informa- tion systems specialists. Technical specialists, such as system analysts and programmers, are responsible for much of the systems analysis, design, and implementation work; end users are limited to providing information requirements and reviewing the technical staff’s work. The lifecycle also emphasizes formal specifications and paperwork, so many documents are generated during the course of a systems project.

The systems lifecycle is still used for building large complex systems that require rigorous and formal requirements analysis, predefined specifications, and tight controls over the systems-building process. However, this approach is also time-consuming and expensive to use. Tasks in one stage are supposed to be completed before work for the next stage

Chapter 11: Building Information Systems and Managing Projects 387

Figure 11-3 The Traditional Systems Development Lifecycle The systems develop- ment lifecycle partitions systems development into formal stages, with each stage requiring completion before the next stage can begin.

IS B

N 1-

25 6-

42 91

3- 9

begins. Activities can be repeated, but volumes of new documents must be generated and steps retraced if requirements and specifications need to be revised. This encourages freezing of specifications relatively early in the development process. The lifecycle approach is also not suitable for many small desktop systems, which tend to be less structured and more individualized.

PROTOTYPING

Prototyping consists of building an experimental system rapidly and inexpensively for end users to evaluate. The prototype is a working version of an information system or part of the system, but it is intended as only a preliminary model. Users interact with the prototype to get a better idea of their information requirements, refining the prototype multiple times. (The chapter-opening case describes how Dovetail Associates used QuickBase to create a prototype that helped the Patriots’ Trail Girl Scout Council refine their specifications for their cookie-ordering system.) When the design is finalized, the prototype will be converted to a polished production system. Figure 11-4 shows a four-step model of the prototyping process.

Step 1: Identify the user’s basic requirements. The system designer (usually an information systems specialist) works with the user only long enough to capture the user’s basic information needs.

Step 2: Develop an initial prototype. The system designer creates a working prototype quickly, using tools for rapidly generating software.

Step 3: Use the prototype. The user is encouraged to work with the system to determine how well the prototype meets his or her needs and to make suggestions for improving the prototype.

Step 4: Revise and enhance the prototype. The system builder notes all changes the user requests and refines the prototype accordingly. After the prototype has been revised, the cycle returns to Step 3. Steps 3 and 4 are repeated until the user is satisfied.

388 Part IV: Building and Managing Systems

Figure 11-4 The Prototyping Process The process of develop- ing a prototype consists of four steps. Because a prototype can be developed quickly and inexpensively, systems builders can go through several iterations, repeating steps 3 and 4, to refine and enhance the prototype before arriving at the final opera- tional one.

IS B

N 1-256-42913-9

Prototyping is especially useful in designing an information system’s user interface. Because prototyping encourages intense end-user involvement throughout the systems-development process, it is more likely to produce systems that fulfill user requirements.

However, rapid prototyping may gloss over essential steps in systems development, such as thorough testing and documentation. If the completed prototype works reasonably well, management may not see the need to build a polished production system. Some hastily constructed systems do not easily accommodate large quantities of data or a large number of users in a production environment.

END-USER DEVELOPMENT

End-user development allows end users, with little or no formal assistance from technical specialists, to create simple information systems, reducing the time and steps required to produce a finished application. Using fourth-generation languages, graphics languages, and PC software tools, end users can access data, create reports, and develop entire information systems on their own, with little or no help from professional systems analysts or programmers.

For example, Elie Tahari Ltd., a leading designer of women’s fashions, uses Information Builders Inc.’s WebFOCUS software to enable authorized users to obtain self-service reports on orders, inventory, sales, and finance. Sales executives use the system to view their accounts, to determine what merchandise is selling, and to see what customers have ordered. Users can also create ad hoc reports by themselves to obtain specific pieces of information or more detailed data (Information Builders, 2009).

On the whole, end-user-developed systems are completed more rapidly than those developed with conventional programming tools. Allowing users to specify their own business needs improves requirements gathering and often leads to a higher level of user involvement and satisfaction with the system. However, fourth-generation tools still cannot replace conventional tools for some business applications because they cannot easily handle the processing of large numbers of transactions or applications with extensive procedural logic and updating requirements.

End-user development also poses organizational risks because systems are created rapidly, without a formal development methodology, testing, and documentation. To help organizations maximize the benefits of end-user applications development, management should require cost justification of end-user information system projects and establish hard- ware, software, and quality standards for user-developed applications.

PURCHASING SOLUTIONS: APPLICATION SOFTWARE PACKAGES AND OUTSOURCING

Chapter 4 points out that the software for most systems today is not developed in-house but is purchased from external sources. Firms may choose to purchase a software pack- age from a commercial vendor, rent the software from a service provider, or outsource the development work to another firm. Selection of the software or software service is often based on a Request for Proposal (RFP), which is a detailed list of questions sub- mitted to external vendors to see how well they meet the requirements for the proposed system.

Application Software Packages Most new information systems today are built using an application software package or preprogrammed software components. Many applications are common to all business organizations—for example, payroll, accounts receivable, general ledger, or inventory control. For such universal functions with standard processes that do not change a great deal over time, a generalized system will fulfill the requirements of many organizations.

Chapter 11: Building Information Systems and Managing Projects 389 IS

B N

1- 25

6- 42

91 3-

If a software package can fulfill most of an organization’s requirements, the company does not have to write its own software. The company saves time and money by using the prewritten, predesigned, pretested software programs from the package.

Many packages include capabilities for customization to meet unique requirements not addressed by the package software. Customization features allow a software package to be modified to meet an organization’s unique requirements without destroying the integrity of the packaged software. However, if extensive customization is required, additional programming and customization work may become so expensive and time-consuming that it negates many of the advantages of software packages. If the package cannot be customized, the organization will have to adapt to the package and change its procedures.

The Interactive Session on Technology describes the experience of Zimbra, a software company that selected a software package solution for its new marketing automation system. As you read this case, try to identify the problem this company was facing, what alternative solutions were available to management, why a software package was an appro- priate solution, and how well the chosen solution worked.

Outsourcing If a firm does not want to use its internal resources to build or operate information systems, it can outsource the work to an external organization that specializes in providing these services. Software service providers, which we describe in Chapter 4, are one form of out- sourcing. An example would be the Girl Scouts leasing the software and hardware from QuickBase to run their cookie-ordering system. Subscribing companies use the software and computer hardware of the service provider as the technical platform for their systems. In another form of outsourcing, a company would hire an external vendor to design and create the software for its system, but that company would operate the system on its own computers.

The outsourcing vendor might be domestic or in another country. Domestic outsourc- ing is driven primarily by the fact that outsourcing firms possess skills, resources, and assets that their clients do not have. Installing a new supply chain management system in a very large company might require hiring an additional 30–50 people with specific expertise in supply chain management software licensed, say, from JDA/Manugistics or another vendor. Rather than hire permanent new employees, most of whom would need extensive training in the software package, and then release them after the new system is built, it makes more sense, and is often less expensive, to outsource this work for a 12- month period.

In the case of offshore outsourcing, the decision tends to be much more cost-driven. A skilled programmer in India or Russia earns about U.S. $10,000 per year, compared to $70,000 per year for a comparable programmer in the United States. The Internet and low-cost communications technology have drastically reduced the expense and difficulty of coordinating the work of global teams in faraway locations. In addition to cost savings, many offshore outsourcing firms offer world-class technology assets and skills.

For example, Pinnacle West Capital Corporation, which sells and delivers electricity and energy-related services to 1 million customers in the western United States, turned to outsourcing to reduce operational costs. It contracted with the Indian software and service provider Wipro Ltd. to handle its application development. Wipro develops Pinnacle West’s applications, services system enhancements, and provides 24-hour system support. Outsourcing to Wipro helped Pinnacle West accomplish 12 months of development work in 7 months while reducing computer processing and application development costs .

There is a very strong chance that at some point in your career, you’ll be working with offshore outsourcers or global teams. Your firm is most likely to benefit from outsourcing if it takes the time to evaluate all the risks and to make sure outsourcing is appropriate for its particular needs. Any company that outsources its applications must thoroughly understand

390 Part IV: Building and Managing Systems IS

B N

1-256-42913-9

INTERACTIVE SESSION: TECHNOLOGY Zimbra Zooms Ahead with OneView

Zimbra is a software company whose flagship product is its Zimbra Collaboration Suite (ZCS), an open source e-mail collaboration suite that relies heavily on Ajax to provide a variety of business functions. Purchased by Yahoo in 2007, the company now has accumulated 50 million paid mailboxes. In addition to e-mail, ZCS combines contact lists, a shared calendar, instant messaging, hosted documents, search, and VoIP into one package, and can be used on any mobile Web browser.

As an open source software company, Zimbra uses viral marketing models, word-of-mouth marketing, and open standards to grow its business. Customers are as free to criticize Zimbra and ZCS as they are to praise the company and its flagship offering. For the most part, this strategy has proven very successful for the company thus far.

Zimbra makes sales via its Web site and offers both free and commercial versions. Zimbra’s business model hinges on driving large numbers of visitors to its Web site, allowing them to try the most basic version of the software for free, and then persuading them to purchase one of its more full-featured commercial versions. Zimbra has over 200,000 visi- tors to its Web site each week.

Zimbra’s sales process begins when one of these 200,000 weekly visitors downloads a 60-day trial version. Salespeople try to identify which people using the trial version are most likely to upgrade to one of its commercial versions and then contact these people via e-mail and telephone to try to close the sale.

To make this work, Zimbra’s sales team needs capa- bililities for weeding out the interested buyers from its huge volume of Web visitors. As Greg Armanini, Zimbra’s director of marketing pointed out, the sales team will be overwhelmed with a ton of unqualified leads unless sales and marketing automation tools are able to focus sales reps only on the leads that will gen- erate revenue. Zimbra uses its Web site to track visitor activity and tie it to sales lead information in its Salesforce.com customer relationship management (CRM) system. Identifying sales prospects that visit the Web site regularly and alerting sales reps when those prospects are visiting the site helps the sales team select which prospects to contact by telephone and when to call them.

Zimbra initially used marketing automation software from Eloqua, which had a large number of features but was too complicated for both marketing and sales staff to use. For example, the Eloqua system required salespeople to code conditional logic for any

data field containing data they wanted to collect. Though doable, this task was a poor usage of Zimbra’s sales staff time. Eloqua only worked with the Internet Explorer Web browser, while two-thirds of Zimbra’s sales department used Mozilla Firefox. And Eloqua was expensive. Zimbra could only afford its entry- level package, which provided access to only five salespeople and one marketing person.

Zimbra did not need many of Eloqua’s features, but it did need a more streamlined solution that focused on the core areas of its marketing strategy: lead generation, e-mail marketing, and Web analytics. The new marketing automation system had to be easy to install and maintain. Many available options required several well-trained administrators, and Zimbra could not afford to allocate even one employee for this purpose.

After examining several software products, Zimbra choose OneView, an on-demand marketing automation solution from LoopFuse, a Georgia-based software company that specializes in sales and market- ing automation. OneView was more highly targeted than the Eloqua software. Not only that, but much of OneView consists of automated processes that allowed Zimbra to quickly implement the solution and to maintain it without dedicating someone to the task full-time. The core functions of OneView include Web site visitor tracking, automated marketing program communication, customer activity alerts, and CRM integration.

Zimbra was also pleased with LoopFuse’s conve- nient pricing options, including its “unlimited seating” and “pay-per-use” options, which allowed Zimbra to pay for only the services it needed for as many users as it required. Because of these options, Zimbra was able to deploy LoopFuse across almost its entire 30-person sales force.

Other benefits of OneView include easy integra- tion with Salesforce.com, Zimbra’s preferred CRM solution, simplified reporting processes, and the ability to manage a larger number of leads thanks to having more salespeople and time to devote to demand generation. OneView works with multiple Web browsers, including Firefox. The old solution offered so many ways to handle and organize data that generating data reports could take a long time. With OneView’s simplified reporting processes, the sales staff can generate reports in a fraction of the time.

Has OneView improved Zimbra’s bottom line? OneView reduced the amount of time Zimbra spent using and maintaining its marketing system by 50

Chapter 11: Building Information Systems and Managing Projects 391 IS

B N

1- 25

6- 42

91 3-

1. Describe the steps in Zimbra’s sales process. How well did its old marketing automation system sup- port that process? What problems did it create? What was the business impact of these problems?

2. List and describe Zimbra’s requirements for a new marketing software package. If you were prepar- ing the RFP for Zimbra’s new system, what questions would you ask?

3. How did the new marketing system change the way Zimbra ran its business? How successful was it?

percent. Zimbra reports that since changing vendors, it has witnessed a jump in its close rate on qualified sales leads from 10 to 15 percent, a huge increase. The answer appears to be a resounding “yes.”

Visit the LoopFuse Web site and then answer the fol- lowing questions:

1. List and describe each of the major features of LoopFuse OneView.

2. Select two of these features and describe how they would help Zimbra’s sales team.

Sources: Jessica Tsai, “Less is More,” Customer Relationship Management, August 2009, www.destinationCRM.com; and “LoopFuse OneView helps Zimbra Raise Sales and Marketing Efficiency by 50 Percent,” www.loopfuse.com, May 2009.

CASE STUDY QUESTIONS MIS IN ACTION

392 Part IV: Building and Managing Systems

the project, including its requirements, method of implementation, source of expected benefits, cost components, and metrics for measuring performance.

Many firms underestimate costs for identifying and evaluating vendors of information technology services, for transitioning to a new vendor, for improving internal software development methods to match those of outsourcing vendors, and for monitoring vendors to make sure they are fulfilling their contractual obligations. Outsourcing offshore incurs additional costs for coping with cultural differences that drain productivity and dealing with human resources issues, such as terminating or relocating domestic employees. These hidden costs undercut some of the anticipated benefits from outsourcing. Firms should be especially cautious when using an outsourcer to develop or to operate applications that give it some type of competitive advantage.

Figure 11-5 shows best- and worst-case scenarios for the total cost of an offshore outsourcing project. It shows how much hidden costs affect the total project cost. The best case reflects the lowest estimates for additional costs, and the worst case reflects the highest estimates for these costs. As you can see, hidden costs increase the total cost of an offshore outsourcing project by an extra 15 to 57 percent. Even with these extra costs, many firms will benefit from offshore outsourcing if they manage the work well.

RAPID APPLICATION DEVELOPMENT FOR E-BUSINESS

Technologies and business conditions are changing so rapidly that agility and scalability have become critical elements of system solutions. Companies are adopting shorter, more informal development processes for many of their e-commerce and e-business applications, processes that provide fast solutions that do not disrupt their core transaction processing systems and organizational databases. In addition to using software packages, application service providers, and other outsourcing services, they are relying more heavily on fast-cycle techniques, such as joint application design (JAD), prototypes, and reusable standardized software components that can be assembled into a complete set of services for e-commerce and e-business.

The term rapid application development (RAD) refers to the process of creating workable systems in a very short period of time. RAD includes the use of visual program-

IS B

N 1-256-42913-9

ming and other tools for building graphical user interfaces, iterative prototyping of key system elements, the automation of program code generation, and close teamwork among end users and information systems specialists. Simple systems often can be assembled from prebuilt components (see Section 11.3). The process does not have to be sequential, and key parts of development can occur simultaneously.

Sometimes a technique called joint application design (JAD) will be used to accelerate the generation of information requirements and to develop the initial systems design. JAD brings end users and information systems specialists together in an interactive session to discuss the system’s design. Properly prepared and facilitated, JAD sessions can significantly speed up the design phase and involve users at an intense level.

11.3 Modeling and Designing Systems

We have just described alternative methods for building systems. There are also alternative methodologies for modeling and designing systems. The two most prominent are structured methodologies and object-oriented development.

STRUCTURED METHODOLOGIES

Structured methodologies have been used to document, analyze, and design information systems since the 1970s. Structured refers to the fact that the techniques are step by step, with each step building on the previous one. Structured methodologies are top-down, progressing from the highest, most abstract level to the lowest level of detail—from the general to the specific.

Structured development methods are process-oriented, focusing primarily on modeling the processes, or actions, that capture, store, manipulate, and distribute data as the data flow through a system. These methods separate data from processes. A separate programming procedure must be written every time someone wants to take an action on a particular piece of data. The procedures act on data that the program passes to them.

The primary tool for representing a system’s component processes and the flow of data between them is the data flow diagram (DFD). The data flow diagram offers a logical graphic model of information flow, partitioning a system into modules that show manage- able levels of detail. It rigorously specifies the processes or transformations that occur within each module and the interfaces that exist between them.

Figure 11-6 shows a simple data flow diagram for a mail-in university course registra- tion system. The rounded boxes represent processes, which portray the transformation of data. The square box represents an external entity, which is an originator or receiver of

Chapter 11: Building Information Systems and Managing Projects 393

Figure 11-5 Total Cost of Offshore Outsourcing If a firm spends $10 million on offshore outsourcing contracts, that company will actu- ally spend 15.2 percent in extra costs even under the best-case scenario. In the worst-case scenario, where there is a dramatic drop in productivity along with exceptionally high transition and layoff costs, a firm can expect to pay up to 57 percent in extra costs on top of the $10 million outlay for an offshore contract.

IS B

N 1-

25 6-

42 91

3- 9

information located outside the boundaries of the system being modeled. The open rectangles represent data stores, which are either manual or automated inventories of data. The arrows represent data flows, which show the movement between processes, external entities, and data stores. They always contain packets of data with the name or content of each data flow listed beside the arrow.

This data flow diagram shows that students submit registration forms with their names, identification numbers, and the numbers of the courses they wish to take. In Process 1.0, the system verifies that each course selected is still open by referencing the university’s course file. The file distinguishes courses that are open from those that have been canceled or filled. Process 1.0 then determines which of the student’s selections can be accepted or rejected. Process 2.0 enrolls the student in the courses for which he or she has been accepted. It updates the university’s course file with the student’s name and identification number and recalculates the class size. If maximum enrollment has been reached, the course number is flagged as closed. Process 2.0 also updates the university’s student master file with informa- tion about new students or changes in address. Process 3.0 then sends each student applicant a confirmation-of-registration letter listing the courses for which he or she is registered and noting the course selections that could not be fulfilled.

Through leveled data flow diagrams, a complex process can be broken down into successive levels of detail. An entire system can be divided into subsystems with a high-level data flow diagram. Each subsystem, in turn, can be divided into additional subsystems with lower-level data flow diagrams, and the lower-level subsystems can be broken down again until the lowest level of detail has been reached. Process specifications describe the transformation occurring within the lowest level of the data flow diagrams, showing the logic for each process.

In structured methodology, software design is modeled using hierarchical structure charts. The structure chart is a top-down chart, showing each level of design, its relation- ship to other levels, and its place in the overall design structure. The design first considers the main function of a program or system, then breaks this function into subfunctions, and decomposes each subfunction until the lowest level of detail has been reached. Figure 11-7 shows a high-level structure chart for a payroll system. If a design has too many levels to fit onto one structure chart, it can be broken down further on more detailed structure charts. A structure chart may document one program, one system (a set of programs), or part of one program.

394 Part IV: Building and Managing Systems

Figure 11-6 Data Flow Diagram for Mail-in University Registration System The system has three processes: Verify availability (1.0), Enroll student (2.0), and Confirm registration (3.0). The name and content of each of the data flows appear adjacent to each arrow. There is one external entity in this system: the student. There are two data stores: the student master file and the course file.

IS B

N 1-256-42913-9

OBJECT-ORIENTED DEVELOPMENT

Structured methods treat data and processes as logically separate entities, whereas in the real world such separation seems unnatural. Different modeling conventions are used for analy- sis (the data flow diagram) and for design (the structure chart).

Object-oriented development addresses these issues. Object-oriented development uses the object, which we introduced in Chapter 4, as the basic unit of systems analysis and design. An object combines data and the specific processes that operate on those data. Data encapsulated in an object can be accessed and modified only by the operations, or methods, associated with that object. Instead of passing data to procedures, programs send a message for an object to perform an operation that is already embedded in it. The system is modeled as a collection of objects and the relationships among them. Because processing logic resides within objects rather that in separate software programs, objects must collaborate with each other to make the system work.

Object-oriented modeling is based on the concepts of class and inheritance. Objects belonging to a certain class, or general categories of similar objects, have the features of that class. Classes of objects in turn inherit all the structure and behaviors of a more general class and then add variables and behaviors unique to each object. New classes of objects are created by choosing an existing class and specifying how the new class differs from the existing class, instead of starting from scratch each time.

We can see how class and inheritance work in Figure 11-8, which illustrates the relationships among classes concerning employees and how they are paid. Employee is the common ancestor, or superclass, for the other three classes. Salaried, Hourly, and Temporary are subclasses of Employee. The class name is in the top compartment, the attributes for each class are in the middle portion of each box, and the list of operations is in the bottom portion of each box. The features that are shared by all employees (ID, name, address, date hired, position, and pay) are stored in the Employee superclass, whereas each subclass stores features that are specific to that particular type of employee. Specific to Hourly employees, for example, are their hourly rates and overtime rates. A solid line from the subclass to the superclass is a generalization path showing that the subclasses Salaried, Hourly, and Temporary have common features that can be generalized into the superclass Employee.

Object-oriented development is more iterative and incremental than traditional structured development. During systems analysis, systems builders document the functional requirements of the system, specifying its most important properties and what the proposed system must do. Interactions between the system and its users are analyzed to identify objects, which include both data and processes. The object-oriented design phase describes how the objects will behave and how they will interact with one other. Similar objects are

Chapter 11: Building Information Systems and Managing Projects 395

Figure 11-7 High-Level Structure Chart for a Payroll System This structure chart shows the highest or most abstract level of design for a payroll system, providing an overview of the entire system.

IS B

N 1-

25 6-

42 91

3- 9

grouped together to form a class, and classes are grouped into hierarchies in which a subclass inherits the attributes and methods from its superclass.

The information system is implemented by translating the design into program code, reusing classes that are already available in a library of reusable software objects and adding new ones created during the object-oriented design phase. Implementation may also involve the creation of an object-oriented database. The resulting system must be thoroughly tested and evaluated.

Because objects are reusable, object-oriented development could potentially reduce the time and cost of writing software if organizations reuse software objects that have already been created as building blocks for other applications. New systems can be created by using some existing objects, changing others, and adding a few new objects.

Component-Based Development, Web Services, and Cloud-Based Development To further expedite software creation, groups of objects have been assembled into software components for common functions, such as a graphical user interface or online ordering capability, and these components can be combined to create large-scale business applications. This approach to software development is called component-based development. Businesses are using component-based development to create their e-commerce applications by combining commercially available components for shopping carts, user authentication, search engines, and catalogs with pieces of software for their own unique business requirements.

Chapter 4 introduced Web services as loosely coupled, reusable software components based on Extensible Markup Language (XML) and other open protocols and standards that enable one application to communicate with another with no custom programming required. In addition to supporting internal and external integration of systems, Web services provide nonproprietary tools for building new information system applications or enhancing existing systems.

Platform as a service, introduced in the Chapter 4 discussion of cloud computing, also holds considerable potential for helping system developers quickly write and test customer- or employee-facing Web applications. These online development environments come from a range of vendors, including Sun, IBM, Salesforce.com (Force.com), and Microsoft (Azure). These platforms automate tasks such as setting up a newly composed application as a Web service or linking to other applications and services. Some also offer a cloud infrastructure

396 Part IV: Building and Managing Systems

Figure 11-8 Class and Inheritance This figure illustrates how classes inherit the common features of their superclass.

IS B

N 1-256-42913-9

service, or links to cloud vendors such as Amazon, so that developers can launch what they build in a cloud infrastructure.

COMPUTER-AIDED SOFTWARE ENGINEERING (CASE)

Computer-aided software engineering (CASE)—sometimes called computer-aided systems engineering—provides software tools to automate the methodologies we have just described to reduce the amount of repetitive work in systems development. CASE tools provide automated graphics facilities for producing charts and diagrams, screen and report generators, data dictionaries, extensive reporting facilities, analysis and checking tools, code generators, and documentation generators. CASE tools also contain features for validating design diagrams and specifications.

CASE tools facilitate clear documentation and coordination of team development efforts. Team members can share their work by accessing each other’s files to review or modify what has been done. Modest productivity benefits are achieved if the tools are used properly. Many CASE tools are PC based, with powerful graphical capabilities.

11.4 Project Management

Your company might have developed what appears to be an excellent system solution. Yet when the system is in use, it does not work properly or it doesn’t deliver the benefits that were promised. If this occurs, your firm is not alone. There is a very high failure rate among information systems projects because they have not been properly managed. The Standish Group consultancy, which monitors IT project success rates, found that only 29 percent of all technology investments were completed on time, on budget, and with all features and functions originally specified (Levinson, 2006). Firms may have incorrectly assessed the business value of the new system or were unable to manage the organizational change required by the new technology. That’s why it’s essential to know how to manage informa- tion systems projects and the reasons why they succeed or fail.

The Interactive Session on People provides an example of a failed project. Kaiser Permanente, one of the largest health management organizations in the United States, was unable to establish its own center for handling kidney transplants. Kaiser opened its transplant center in 2004, but had to shut down the facility less than two years after it opened. A major factor was the company’s mismanagement of information and information systems.

PROJECT MANAGEMENT OBJECTIVES

A project is a planned series of related activities for achieving a specific business objective. Information systems projects include the development of new information systems, enhancement of existing systems, or projects for replacement or upgrading of the firm’s information technology (IT) infrastructure.

Project management refers to the application of knowledge, skills, tools, and techniques to achieve specific targets within specified budget and time constraints. Project management activities include planning the work, assessing risk, estimating resources required to accomplish the work, organizing the work, acquiring human and material resources, assigning tasks, directing activities, controlling project execution, reporting progress, and analyzing the results. As in other areas of business, project management for information systems must deal with five major variables: scope, time, cost, quality, and risk.

Scope defines what work is or is not included in a project. For example, the scope of a project for a new order processing system might include new modules for inputting orders and transmitting them to production and accounting but not any changes to related accounts receivable, manufacturing, distribution, or inventory control systems. Project management defines all the work required to complete a project successfully, and should ensure that the scope of a project does not expand beyond what was originally intended.

Chapter 11: Building Information Systems and Managing Projects 397 IS

B N

1- 25

6- 42

91 3-

INTERACTIVE SESSION: PEOPLE Kaiser Permanente Botches Its Kidney Transplant Center Project

Kaiser Permanente is one of the country’s foremost health maintenance organizations (HMOs), also referred to as integrated managed care organizations. HMOs provide health care that is fulfilled by hospitals, doctors, and other providers with which the HMO has a contract. While Kaiser is a non-profit organization, the company earned $34.4 billion in revenues in 2007. Kaiser has approximately 170,000 employees, over 13,000 doctors, and serves 8.7 million members in nine states. The company is headquartered in Oakland, CA.

Kaiser is known for pioneering electronic medical records and currently boasts the world’s largest electronic medical record storage system. The company also consistently ranks among the top HMOs in customer satisfaction. However, a 2004 attempt by Kaiser to handle kidney transplants on its own by setting up a transplant center was a public relations and information technology disaster. The company forced its members to transfer to its kidney transplant program without having adequately prepared to treat those patients.

In 2004, Kaiser implemented a kidney transplant program in Northern California under which trans- plants would be performed in-house at a transplant center owned and managed by Kaiser. Previously, the HMO had contracted with nearby university-affiliated California hospitals, such as UC San Francisco and UC Davis. The fledgling transplant center was shut down just two years later because of a litany of mistakes pertaining to paperwork, technology, and procedural planning. Through the duration of the doomed project, twice as many people died waiting for a transplant as received successful transplants. Patients now receive care from local hospitals once again.

Kaiser did very little correctly in its attempt to create its own kidney transplant program. The com- pany lost track of records when transferring them to the new transplant center. More than 1,000 of the 1,500 patient records had incomplete or incorrect data, such as erroneous social security numbers and missing test results. Despite Kaiser’s longtime expe- rience with electronic medical records, the new cen- ter’s records were stored primarily on paper. Kaiser had no comprehensive transplant patient master list or database. Many other transplant programs have multiple IT professionals assigned to maintain the complicated databases required for a transplant program. Kaiser attempted to run such a program without similar resources. Kaiser employees dedi- cated to processing information on prospective trans- plant recipients were overworked, logging 10- to 16-

hour days as they tried to keep up with the avalanche of information. The company did not accurately anticipate the personnel requirements of their under- taking.

These were by no means the company’s only mistakes, however. There were no specific procedures for transferring data on the initial patients to the United Network for Organ Sharing (UNOS), which oversees national transplant waiting lists. There were no systematic processes for tracking or responding to patient complaints or requests. The Kaiser staff lacked guidance and training regarding their job requirements and uniformly lacked prior experience with transplant programs. And there was no executive governance to identify and correct any of these procedural problems that arose almost immediately after the beginning of the project. Kaiser had seemingly made no attempt to identify and define the processes required to ensure a smooth transition from external transplant programs to an in-house program.

Kaiser also failed to give patients credit for time spent on waiting lists at other hospitals, sometimes dropping patients who had waited the longest down to the bottom of the list. Unlike other companies, IT mismanagement in health care companies can cost individuals their lives, and in Kaiser’s case many plaintiffs seeking damages against the company believe the errors surrounding the Kaiser transplant center have done just that.

At the outset of the transition, Kaiser mailed potential kidney recipients consent forms but did not offer specific directions about what to do with the forms. Many patients failed to respond to the letter, unsure of how to handle it, and others returned the forms to the wrong entity. Other patients were unable to correct inaccurate information, and as a result, UNOS was not able to approve those patients for inclusion on Kaiser’s repopulated kidney wait list.

Despite all of the IT mishaps, the medical aspect of the transplant program was quite successful. All 56 transplant recipients in the first full year of business were still living one year later, which is considered to be strong evidence of high quality. But as the organiza- tional woes continued to mount, Kaiser was forced to shut the program down in 2006, absorbing heavy losses and incurring what figures to be considerable legal expenses.

Kaiser paid a $2 million fine to be levied by the California Department of Managed Health Care (DMHC) for the various state and federal regulations it failed to adhere to in its attempt to set up a transplant

398 Part IV: Building and Managing Systems IS

B N

1-256-42913-9

program. Kaiser was also forced to make a $3 million charitable donation.

Many families of people who died waiting for kidneys from Kaiser are suing the company for med- ical negligence and wrongful death. Other patients, such as Bernard Burks, are going after Kaiser them- selves for the same reasons. In March 2008, Burks won the right to have his case heard by a jury in a pub- lic courtroom, rather than a private judge or lawyer in

arbitration. Most patient disputes with Kaiser are tra- ditionally settled behind closed doors, presumably to minimize the damage to the company’s reputation and increase the likelihood of winning their cases. Burks was the first of over 100 patients on Kaiser’s kidney transplant waiting list to win the right to a jury trial.

Sources: Marie-Anne Hogarth, “Kidney Patient Beats Kaiser Arbitration Rule,” East Bay Business Times, March 21, 2008 and Kim S. Nash, “We Really Did Screw Up,” Baseline Magazine, May, 2007.

1. Classify and describe the problems Kaiser faced in setting up the transplant center. What was the role of information systems and information man- agement in these problems?

2. What were the people, organization, and technol- ogy factors responsible for those problems?

3. What steps would you have taken to increase the project’s chances for success?

4. Were there any ethical problems created by this failed project? Explain your answer.

Explore the Web site for TeleResults (www.telere- sults.com), a provider of state-of-the-art electronic medical record (EMR) solutions and transplant soft- ware, then answer the following question:

1. How could this company’s products have helped Kaiser Permanente manage transplant informa- tion?

CASE STUDY QUESTIONS MIS IN ACTION

Chapter 11: Building Information Systems and Managing Projects 399

Time is the amount of time required to complete the project. Project management typically establishes the amount of time required to complete major components of a project. Each of these components is further broken down into activities and tasks. Project management tries to determine the time required to complete each task and establish a schedule for completing the work.

Cost is based on the time to complete a project multiplied by the daily cost of human resources required to complete the project. Information systems project costs also include the cost of hardware, software, and work space. Project management develops a budget for the project and monitors ongoing project expenses.

Quality is an indicator of how well the end result of a project satisfies the objectives specified by management. The quality of information systems projects usually boils down to improved organizational performance and decision making. Quality also consid- ers the accuracy and timeliness of information produced by the new system and ease of use.

Risk refers to potential problems that would threaten the success of a project. These potential problems might prevent a project from achieving its objectives by increasing time and cost, lowering the quality of project outputs, or preventing the project from being completed altogether. We discuss the most important risk factors for information systems projects later in this section.

SELECTING PROJECTS: MAKING THE BUSINESS CASE FOR A NEW SYSTEM

Companies typically are presented with many different projects for solving problems and improving performance. There are far more ideas for systems projects than there are resources. You will need to select the projects that promise the greatest benefit to the business. IS

B N

1- 25

6- 42

91 3-

Determining Project Costs and Benefits As we pointed out earlier, the systems analysis includes an assessment of the economic feasibility of each alternative solution—whether each solution represents a good investment for the company. In order to identify the information systems projects that will deliver the most business value, you’ll need to identify their costs and benefits and how they relate to the firm’s information systems plan.

Table 11.3 lists some of the more common costs and benefits of systems. Tangible benefits can be quantified and assigned a monetary value. Intangible benefits, such as more efficient customer service or enhanced decision making, cannot be immediately quantified. Yet systems that produce mainly intangible benefits may still be good investments if they produce quantifiable gains in the long run.

To determine the benefits of a particular solution, you’ll need to calculate all of its costs and all of its benefits. Obviously, a solution where costs exceed benefits should be rejected. But even if the benefits outweigh the costs, some additional financial analysis is required to determine whether the investment represents a good return on the firm’s invested capital. Capital budgeting methods, such as net present value, internal rate of return (IRR), or account- ing rate of return on investment (ROI), would typically be employed to evaluate the proposed information system solution as an investment. You can find out more about how these capital budgeting methods are used to justify information system investments in our Learning Tracks.

Some of the tangible benefits obtained by the Girl Scouts were increased productivity and lower operational costs resulting from automating the ordering process and from reducing errors. Intangible benefits included enhanced volunteer job satisfaction and improved operations.

The Information Systems Plan An information systems plan shows how specific information systems fit into a company’s overall business plan and business strategy. Table 11.4 lists the major components of such a

400 Part IV: Building and Managing Systems

TABLE 11.3

Costs and Benefits of Information Systems

IMPLEMENTATION COSTS Hardware

Telecommunications

Software

Personnel costs

OPERATIONAL COSTS

Computer processing time

Maintenance

Operating staff

User time

Ongoing training costs

Facility costs

TANGIBLE BENEFITS

Increased productivity

Lower operational costs

Reduced workforce

Lower computer expenses

Lower outside vendor costs

Lower clerical and professional costs

Reduced rate of growth in expenses

Reduced facility costs

Increased sales

INTANGIBLE BENEFITS

Improved asset utilization

Improved resource control

Improved organizational planning

Increased organizational flexibility

More timely information

More information

Increased organizational learning

Legal requirements attained

Enhanced employee goodwill

Increased job satisfaction

Improved decision making

Improved operations

Higher client satisfaction

Better corporate image

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 401

TABLE 11.4

Information Systems Plan

1. Purpose of the Plan Overview of plan contents Current business organization and future organization Key business processes Management strategy

2. Strategic Business Plan Rationale Current situation Current business organization Changing environments Major goals of the business plan Firm’s strategic plan

3. Current Systems Major systems supporting business functions and processes Current infrastructure capabilities

Hardware Software Database Telecommunications and the Internet

Difficulties meeting business requirements Anticipated future demands

4. New Developments New system projects

Project descriptions Business rationale Applications’ role in strategy

New infrastructure capabilities required Hardware Software Database Telecommunications and the Internet

5. Management Strategy Acquisition plans Milestones and timing Organizational realignment Internal reorganization Management controls Major training initiatives Personnel strategy

6. Implementation of the Plan Anticipated difficulties in implementation Progress reports

7. Budget Requirements Requirements Potential savings Financing Acquisition cycle

plan. The plan contains a statement of corporate goals and specifies how information technology will help the business attain these goals. The report shows how general goals will be achieved by specific systems projects. It identifies specific target dates andIS

B N

1- 25

6- 42

91 3-

milestones that can be used later to evaluate the plan’s progress in terms of how many objectives were actually attained in the time frame specified in the plan. The plan indicates the key management decisions concerning hardware acquisition; telecommunications; centralization/decentralization of authority, data, and hardware; and required organizational change.

The plan should describe organizational changes, including management and employee training requirements, changes in business processes, and changes in authority, structure, or management practice. When you are making the business case for a new information system project, you show how the proposed system fits into that plan.

Portfolio Analysis Once you have determined the overall direction of systems development, portfolio analysis will help you evaluate alternative system projects. Portfolio analysis inventories all of the firm’s information systems projects and assets, including infrastructure, outsourcing contracts, and licenses. This portfolio of information systems investments can be described as having a certain profile of risk and benefit to the firm (see Figure 11-9), similar to a financial portfolio. Each information systems project carries its own set of risks and benefits. Firms try to improve the return on their information system portfolios by balancing the risk and return from their systems investments.

Obviously, you begin first by focusing on systems of high benefit and low risk. These promise early returns and low risks. Second, high-benefit, high-risk systems should be examined; low-benefit, high-risk systems should be totally avoided; and low-benefit, low-risk systems should be reexamined for the possibility of rebuilding and replacing them with more desirable systems having higher benefits. By using portfolio analysis, manage- ment can determine the optimal mix of investment risk and reward for their firms, balancing riskier, high-reward projects with safer, lower-reward ones.

The U.S. Army’s Office of the CIO/G-6, which oversees an annual IT budget of more than $7 billion and manages over 1,500 systems and programs, uses portfolio analysis to inventory, evaluate, and rank its IT investments. Portfolio analysis helped the Office identify redundant systems and ensure that its IT investments provide needed capabilities.

Another method for evaluating alternative system solutions is a scoring model. Scoring models give alternative systems a single score based on the extent to which they meet selected objectives. Table 11.5 shows part of a simple scoring model that could have been used by the Girl Scouts in evaluating their alternative systems. The first column lists the criteria that decision makers use to evaluate the systems. Table 11.5 shows that the Girl Scouts attach the most importance to capabilities for sales order processing, ease of use, ability to support users in many different locations, and low cost. The second column in Table 11.5 lists the weights that decision makers attached to the decision criteria. Columns 3 and 5 show the percentage of requirements for each function that each alternative system

402 Part IV: Building and Managing Systems

Figure 11-9 A System Portfolio Companies should examine their portfolio of projects in terms of potential benefits and likely risks. Certain kinds of projects should be avoided altogether and others developed rapidly. There is no ideal mix. Companies in different industries have different information systems needs.

IS B

N 1-256-42913-9

meets. Each alternative’s score is calculated by multiplying the percentage of requirements met for each function by the weight attached to that function. The QuickBase solution has the highest total score.

MANAGING PROJECT RISK AND SYSTEM-RELATED CHANGE

Some systems development projects are more likely to run into problems or to suffer delays because they carry a much higher level of risk than others. The level of project risk is influenced by project size, project structure, and the level of technical expertise of the information systems staff and project team. The larger the project—as indicated by the dollars spent, project team size, and how many parts of the organization will be affected by the new system—the greater the risk. Very large-scale systems projects have a failure rate that is 50 to 75 percent higher than that for other projects because such projects are complex and difficult to control. Risks are also higher for systems where information requirements are not clear and straightforward or the project team must master new technology.

Chapter 11: Building Information Systems and Managing Projects 403

TABLE 11.5

Example of a Scoring Model for the Girl Scouts Cookie System

Criteria Weight Microsoft Access Microsoft Access QuickBase QuickBase System (%) System Score System (%) System Score

1.0 Order processing

1.1 Online order entry 5 67 335 83 415

1.2 Order tracking by troop 5 81 405 87 435

1.3 Order tracking by 5 72 360 80 400 individual Girl Scout

1.4 Reserving warehouse pickups 3 66 198 79 237

Total order processing 1,298 1,487

2.0 Ease of use

2.1 Web access from multiple 5 55 275 92 460 locations

2.2 Short training time 4 79 316 85 340

2.3 User-friendly screens and 4 65 260 87 348 data entry forms

Total ease of use 851 1,148

3.0 Costs

3.1 Software costs 3 51 153 65 195

3.2 Hardware (server) costs 4 57 228 90 360

3.3 Maintenance and 4 42 168 89 356 support costs

Total costs 549 911

Grand Total 2,698 3,546

IS B

N 1-

25 6-

42 91

3- 9

Implementation and Change Management Dealing with these project risks requires an understanding of the implementation process and change management. A broader definition of implementation refers to all the organiza- tional activities working toward the adoption and management of an innovation, such as a new information system. Successful implementation requires a high level of user involve- ment in a project and management support.

If users are heavily involved in the development of a system, they have more opportuni- ties to mold the system according to their priorities and business requirements, and more opportunities to control the outcome. They also are more likely to react positively to the completed system because they have been active participants in the change process. Incorporating user knowledge and expertise leads to better solutions.

The relationship between end users and information systems specialists has traditionally been a problem area for information systems implementation efforts because of differing back- grounds, interests, and priorities. These differences create a user-designer communications gap. Information systems specialists often have a highly technical orientation to problem solving, focusing on technical solutions in which hardware and software efficiency is optimized at the expense of ease of use or organizational effectiveness. End users prefer systems that are oriented toward solving business problems or facilitating organizational tasks. Often the orientations of both groups are so at odds that they appear to speak in different tongues.

These differences are illustrated in Table 11.6, which depicts the typical concerns of end users and technical specialists (information systems designers) regarding the development of a new information system. Communication problems between end users and designers are a major reason why user requirements are not properly incorporated into information systems and why users are driven out of the implementation process.

If an information systems project has the backing and commitment of management at various levels, it is more likely to receive higher priority from both users and the technical information systems staff. Management backing also ensures that a systems project receives sufficient funding and resources to be successful. Furthermore, to be enforced effectively, all the changes in work habits and procedures and any organizational realignments associated with a new system depend on management backing.

Controlling Risk Factors There are strategies you can follow to deal with project risk and increase the chances of a successful system solution. If the new system involves challenging and complex technology, you can recruit project leaders with strong technical and administrative experience. Outsourcing or using external consultants are options if your firm does not have staff with the required technical skills or expertise.

404 Part IV: Building and Managing Systems

TABLE 11.6

The User-Designer Communications Gap

User Concerns Designer Concerns

Will the system deliver the information I need How much disk storage space will the master for my work? file consume?

How quickly can I access the data? How many lines of program code will it take to perform this function?

How easily can I retrieve the data? How can we cut down on CPU time when we run the system?

How much clerical support will I need to enter What is the most efficient way of storing data into the system? the data?

How will the operation of the system fit into What database management system should my daily business schedule? we use?

IS B

N 1-256-42913-9

Large projects benefit from appropriate use of formal planning and tools for documenting and monitoring project plans. The two most commonly used methods for documenting project plans are Gantt charts and PERT charts. A Gantt chart lists project activities and their corresponding start and completion dates. The Gantt chart visually represents the timing and duration of different tasks in a development project as well as their human resource requirements (see Figure 11-10). It shows each task as a horizontal bar whose length is proportional to the time required to complete it.

Although Gantt charts show when project activities begin and end, they don’t depict task dependencies, how one task is affected if another is behind schedule, or how tasks should be ordered. That is where PERT charts are useful. PERT stands for Program Evaluation and Review Technique, a methodology developed by the U.S. Navy during the 1950s to manage the Polaris submarine missile program. A PERT chart graphically depicts project tasks and their interrelationships. The PERT chart lists the specific activities that make up a project and the activities that must be completed before a specific activity can start, as illustrated in Figure 11-11.

The PERT chart portrays a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing project tasks. Each node is numbered and shows the task, its duration, the starting date, and the completion date. The direction of the arrows on the lines indicates the sequence of tasks and shows which activities must be completed before the commencement of another activity. In Figure 11-11, the tasks in nodes 2, 3, and 4 are not dependent on each other and can be undertaken simultaneously, but each is dependent on completion of the first task.

Project Management Software Commercial software tools are available to automate the creation of Gantt and PERT charts and to facilitate the project management process. Project management software typically features capabilities for defining and ordering tasks, assigning resources to tasks, establishing starting and ending dates for tasks, tracking progress, and facilitating modifications to tasks and resources. The most widely used project management tool today is Microsoft Office Project.

Overcoming User Resistance You can overcome user resistance by promoting user participation (to elicit commitment as well as to improve design), by making user education and training easily available, and by pro- viding better incentives for users who cooperate. End users can become active members of the project team, take on leadership roles, and take charge of system installation and training.

You should pay special attention to areas where users interface with the system, with sensitivity to ergonomics issues. Ergonomics refers to the interaction of people and machines in the work environment. It considers the design of jobs, health issues, and the end-user interface of information systems. For instance, if a system has a series of complicated online data entry screens that are extremely difficult or time-consuming to work with, users will reject the system if it increases their work load or level of job stress.

Users will be more cooperative if organizational problems are solved prior to introducing the new system. In addition to procedural changes, transformations in job functions, organizational structure, power relationships, and behavior should be identified during systems analysis using an organizational impact analysis.

MANAGING PROJECTS ON A GLOBAL SCALE

As globalization proceeds, companies will be building many more new systems that are global in scale, spanning many different units in many different countries. The project management challenges for global systems are similar to those for domestic systems, but they are complicated by the international environment. User information requirements, business processes, and work cultures differ from country to country. It is difficult to convince local managers anywhere in the world to change their business processes and ways of working to align with units in other countries, especially if this might interfere with their local performance.

Chapter 11: Building Information Systems and Managing Projects 405 IS

B N

1- 25

6- 42

91 3-

406 Part IV: Building and Managing Systems

Figure 11-10 A Gantt Chart The Gantt chart in this figure shows the task, person-days, and initials of each responsible person, as well as the start and finish dates for each task. The resource summary provides a good manager with the total person-days for each month and for each person working on the project to manage the project successfully. The project described here is a data administration project.

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 407

Figure 11-11 A PERT Chart This is a simplified PERT chart for creating a small Web site. It shows the ordering of project tasks and the relationship of a task with preceding and succeeding tasks.

Involving people in change, and assuring them that change is in the best interests of the company and their local units, is a key tactic for convincing users to adopt global systems and standards. Information systems projects should involve users in the design process with- out giving up control over the project to parochial interests.

One tactic is to permit each country unit in a global corporation to develop one transna- tional application first in its home territory, and then throughout the world. In this manner, each major country systems group is given a piece of the action in developing a transnational system, and local units feel a sense of ownership in the transnational effort. On the downside, this assumes the ability to develop high-quality systems is widely distributed, and that, a German team, for example, can successfully implement systems in France and Italy. This will not always be the case.

A second tactic is to develop new transnational centers of excellence, or a single center of excellence. These centers draw heavily from local national units, are based on multinational teams, and must report to worldwide management. Centers of excellence perform the business and systems analysis and accomplish all design and testing. Implementation, however, and pilot testing are rolled out to other parts of the globe. Recruiting a wide range of local groups to transnational centers of excellence helps send the message that all significant groups are involved in the design and will have an influence.

11.5 Hands-On MIS Projects

The projects in this section give you hands-on experience evaluating information systems projects, designing and building a customer system for auto sales, and analyzing Web site information requirements.IS

B N

1- 25

6- 42

91 3-

MANAGEMENT DECISION PROBLEMS

1. In 2001, McDonald’s Restaurants undertook a project called Innovate to create an intranet connecting headquarters with its 30,000 restaurants in 120 countries to provide detailed operational information in real time. The new system would, for instance, inform a manager at the company’s Oak Brook, Illinois, headquarters immediately if sales were slowing at a franchise in London, or if the grill temperature in a Rochester, Minnesota, restaurant wasn’t hot enough. The idea was to create a global enterprise resource planning application touching the workings of every McDonald’s restaurant. Some of these restaurants were in countries that lacked network infrastructures. After spending over $1 billion over several years, including $170 million on consultants and initial implementation planning, McDonalds terminated the project. What should man- agement have known or done at the outset to prevent this outcome?

2. Caterpillar is the world’s leading maker of earthmoving machinery and supplier of agricultural equipment. Caterpillar wants to end its support for its Dealer Business System (DBS), which it licenses to its dealers to help them run their businesses. The software in this system is becoming outdated, and senior management wants to transfer support for the hosted version of the software to Accenture Consultants so Caterpillar can concentrate on its core business. Caterpillar never required its dealers to use DBS, but the system had become a de-facto standard for doing business with the company. The majority of the 50 Cat dealers in North America use some version of DBS, as do about half of the 200 or so Cat dealers in the rest of the world. Before Caterpillar turns the product over to Accenture, what factors and issues should it con- sider? What questions should it ask? What questions should its dealers ask?

IMPROVING DECISION MAKING: USING DATABASE SOFTWARE TO DESIGN A CUSTOMER SYSTEM FOR AUTO SALES

Software skills: Database design, querying, reporting, and forms Business skills: Sales lead and customer analysis

This project requires you to perform a systems analysis and then design a system solution using database software.

Ace Auto Dealers specializes in selling new vehicles from Subaru. The company advertises in local newspapers and also is listed as an authorized dealer on the Subaru Web site and other major Web sites for auto buyers. The company benefits from a good local word-of-mouth reputation and name recognition and is a leading source of information for Subaru vehicles in the Portland, Oregon, area.

When a prospective customer enters the showroom, he or she is greeted by an Ace sales representative. The sales representative manually fills out a form with information such as the prospective customer’s name, address, telephone number, date of visit, and make and model of the vehicle in which the customer is interested. The representative also asks where the prospect heard about Ace—whether it was from a newspaper ad, the Web, or word of mouth—and this information is noted on the form also. If the customer decides to purchase an auto, the dealer fills out a bill of sale form.

Ace does not believe it has enough information about its customers. It cannot easily determine which prospects have made auto purchases, nor can it identify which customer touch points have produced the greatest number of sales leads or actual sales so it can focus advertising and marketing more on the channels that generate the most revenue. Are purchasers discovering Ace from newspaper ads, from word of mouth, or from the Web?

Prepare a systems analysis report detailing Ace’s problem and a system solution that can be implemented using PC database management software. Then use database software to develop a simple system solution. Your systems analysis report should include the following:

408 Part IV: Building and Managing Systems IS

B N

1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 409

• Description of the problem and its organizational and business impact. • Proposed solution, solution objectives, and solution feasibility. • Costs and benefits of the solution you have selected. The company has a PC with

Internet access and the full suite of Microsoft Office desktop productivity tools. • Information requirements to be addressed by the solution. • People, organization, and technology issues to be addressed by the solution, including

changes in business processes.

On the basis of the requirements you have identified, design the database and populate it with at least 10 records per table. Consider whether you can use or modify the existing customer database in your design. Print out the database design. Then use the system you have created to generate queries and reports that would be of most interest to management. Create several prototype data input forms for the system and review them with your instructor. Then revise the prototypes.

ACHIEVING OPERATIONAL EXCELLENCE: ANALYZING WEB SITE DESIGN AND INFORMATION REQUIREMENTS

Software skills: Web browser software Business skills: Information requirements analysis, Web site design

Visit the Web site of your choice and explore it thoroughly. Prepare a report analyzing the various functions provided by that Web site and its information requirements. Your report should answer these questions: What functions does the Web site perform? What data does it use? What are its inputs, outputs, and processes? What are some of its other design specifications? Does the Web site link to any internal systems or systems of other organiza- tions? What value does this Web site provide the firm?

LEARNING TRACKS

The following Learning Tracks provide content relevant to topics covered in this chapter:

1. Capital Budgeting Methods for Information System Investments

2. Enterprise Analysis (Business Systems Planning) and Critical Success Factors (CSFs)

3. Unified Modeling Language (UML)

4. IT Investments and Productivity

Review Summary

1 What are the core problem-solving steps for developing new informationsystems? The core problem-solving steps for developing new information systems are: (1) define and understand the problem, (2) develop alternative solutions, (3) evaluate and choose the solution, and (4) implement the solution. The third step includes an assessment of the technical, financial, and organizational feasibility of each alternative. The fourth step entails finalizing design specifications, acquiring hardware and software, testing, providing training and documentation, conversion, and evaluating the system solution once it is in production.IS

B N

1- 25

6- 42

91 3-

410 Part IV: Building and Managing Systems

2 What are the alternative methods for building information systems? The systemslifecycle requires that information systems be developed in formal stages. The stages must proceed sequentially and have defined outputs; each requires formal approval before the next stage can commence. The system lifecycle is rigid and costly but nevertheless useful for large projects.

Prototyping consists of building an experimental system rapidly and inexpensively for end users to interact with and evaluate. The prototype is refined and enhanced until users are satisfied that it includes all of their requirements and can be used as a template to create the final system. End-user-developed systems can be created rapidly and informally using fourth-generation software tools. End-user development can improve requirements determination and reduce application backlog.

Application software packages eliminate the need for writing software programs when developing an information system. Application software packages are helpful if a firm does not have the internal information systems staff or financial resources to custom-develop a system.

Outsourcing consists of using an external vendor to build (or operate) a firm’s informa- tion systems. If it is properly managed, outsourcing can save application development costs or enable firms to develop applications without an internal information systems staff.

Rapid application design, joint application design (JAD), cloud-based platforms, and reusable software components (including Web services) can be used to speed up the systems development process.

3 What are the principal methodologies for modeling and designing systems? The two principal methodologies for modeling and designing information systems are structured methodologies and object-oriented development. Structured methodologies focus on modeling processes and data separately. The data flow diagram is the principal tool for structured analysis, and the structure chart is the principal tool for representing structured software design. Object-oriented development models a system as a collection of objects that combine processes and data.

4 How should information systems projects be selected and evaluated? To determine whether an information system project is a good investment, one must calculate its costs and benefits. Tangible benefits are quantifiable, and intangible benefits cannot be immediately quantified but may provide quantifiable benefits in the future. Benefits that exceed costs should then be analyzed using capital budgeting methods to make sure they represent a good return on the firm’s invested capital.

Organizations should develop information systems plans that describe how information technology supports the company’s overall business plan and strategy. Portfolio analysis and scoring models can be used to evaluate alternative information systems projects.

5 How should information systems projects be managed? Information systemsprojects and the entire implementation process should be managed as planned organizational change using an organizational impact analysis. Management support and control of the implementation process are essential, as are mechanisms for dealing with the level of risk in each new systems project. Project risks are influenced by project size, project structure, and the level of technical expertise of the information systems staff and project team. Formal planning and control tools (including Gantt and PERT charts) track the resource allocations and specific project activities. Users can be encouraged to take active roles in systems development and become involved in installation and training. Global information systems projects should involve local units in the creation of the design without giving up control of the project to parochial interests.

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 411

Information systems plan, 400

Intangible benefits, 400 Joint application design

(JAD), 393 Maintenance, 386 Object-oriented

development, 395 Organizational impact

analysis, 405 Parallel strategy, 386 PERT charts, 405 Phased approach, 386 Portfolio analysis, 402 Process specifications, 394 Production, 386 Project, 397 Project management, 397 Prototyping, 388

Rapid application development (RAD), 392

Request for Proposal (RFP), 389

Scope, 397 Scoring model, 402 Structure chart, 394 Structured, 393 System testing, 384 Systems analysis, 382 Systems design, 383 Systems development

lifecycle (SDLC), 387 Tangible benefits, 400 Test plan, 384 Testing, 384 Unit testing, 384 User-designer communica-

tions gap, 404

Acceptance testing, 384 Component-based

development, 396 Computer-aided software

engineering (CASE), 397 Conversion, 386 Customization, 390 Data flow diagram

(DFD), 393 Direct cutover strategy, 386 Documentation, 384 End-user development, 389 Ergonomics, 405 Feasibility study, 383 Formal planning and

tools, 405 Gantt chart, 405 Implementation, 404 Information

requirements, 382

Key Terms

Review Questions

1. What are the core problem-solving steps for developing new information systems? • List and describe the problem-solving steps for building a new system. • Define information requirements and explain why they are important for developing a

system solution. • List the various types of design specifications required for a new information system. • Explain why the testing stage of systems development is so important. Name and

describe the three stages of testing for an information system. • Describe the roles of documentation, conversion, production, and maintenance in

systems development.

2. What are the alternative methods for building information systems? • Define the traditional systems lifecycle and describe its advantages and disadvantages

for systems building. • Define information system prototyping and describe its benefits and limitations. List and

describe the steps in the prototyping process. • Define end-user development and explain its advantages and disadvantages. • Describe the advantages and disadvantages of developing information systems based on

application software packages. • Define outsourcing. Describe the circumstances in which it should be used for building

information systems. List and describe the hidden costs of offshore software outsourcing.

• Explain how businesses can rapidly develop e-business applications.

3. What are the principal methodologies for modeling and designing systems? • Compare object-oriented and traditional structured approaches for modeling and

designing systems.

4. How should information systems projects be selected and evaluated? • Explain the difference between tangible and intangible benefits. • List six tangible benefits and six intangible benefits.IS

B N

1- 25

6- 42

91 3-

• List and describe the major components of an information systems plan. • Describe how portfolio analysis and scoring models can be used to establish the worth of

systems.

5. How should information systems projects be managed? • Explain the importance of implementation for managing the organizational change

surrounding a new information system. • Define the user-designer communications gap and explain the kinds of implementation

problems it creates. • List and describe the factors that influence project risk and describe strategies for

minimizing project risks. • Describe tactics for managing global projects.

412 Part IV: Building and Managing Systems

Video Cases

Video Cases and Instructional Videos illustrating some of the concepts in this chapter are available. Contact your instructor to access these videos.

Collaboration and Teamwork

Preparing Web Site Design Specifications With three or four of your classmates, select a system described in this text that uses the Web. Review the Web site for the system you select. Use what you have learned from the Web site and the description in this book to prepare a report describing some of the design specifications for the system you select. If possible, use Google Sites to post links to Web pages, team communication announcements, and work assignments; to brainstorm; and to work collaboratively on project documents. Try to use Google Docs to develop a presenta- tion of your findings for the class.

Discussion Questions

1. Discuss the role of business end users and information system professionals in devel- oping a system solution. How do both roles differ when the solution is developed using prototyping or end-user development?

2. It has been said that systems fail when systems builders ignore “people” problems. Why might this be so?

IS B

N 1-256-42913-9

Chapter 11: Building Information Systems and Managing Projects 413

BUSINESS PROBLEM-SOLVING CASE

The U.S. Census Bureau Field Data Collection Project: Don’t Count On It

census to Harris Corp. Due to the immaturity of the mobile technology selected and the inexperience of Harris regarding projects of this size and scale, it was important that the bureau give accurate system requirements and scheduling information, which it failed to do. Implementations of mobile technology tend to be very complicated, requiring sound management and careful planning. The systems have a variety of components, carriers, devices, and applications to organize and coordinate.

Census Bureau Director Steve Murdock testified before Congress in April 2008 that the Census Bureau had failed to effectively convey the complexity of census operations or the project’s IT requirements to Harris. The initial contract contained 600 requirements for the mobile handheld systems, but the Census Bureau later added 418 more. The constant addition of more require- ments made designing the product unnecessarily difficult. The bureau did not press Harris hard enough to provide continued updates on project progress. Yet Harris also did not present the bureau with an accurate initial estimate to begin with.

The struggles of the FCDA don’t threaten the completion of the 2010 census. It will occur as scheduled, but will be far less efficient and cost a great deal more, approximately $3 billion in additional fund- ing over five years. The bureau will do what it can with the mobile devices it has and continue to rely on paper. The mobile handhelds will be used to initially canvas addresses, but won’t be able to be used during the second-stage canvassing of people who don’t respond to initial census questionnaires. The bureau will consequently be forced to abandon several new initia- tives to ensure accurate coverage of areas that have been traditionally undercounted.

The initial estimate was that rolling out mobile devices and providing complementary systems would cost $3 billion of a total $11.5 billion project cost. The total costs of the 2010 census will approach $14.5 billion, well over the initial budget. The bureau’s blunders set census modernization back at least another decade. The bulk of the FDCA “dress rehearsal” was slated to take place during 2008 and 2009 in order to ensure the success of the handheld devices in 2010, but these setbacks forced the rehearsal to be less compre- hensive than was originally planned.

The GAO had reported in March 2006 that the FDCA had not adequately prepared to effectively manage the FDCA program. In that report, the agency cited lack of validated and approved baseline requirements for the

The U.S. Census is an enumeration of the American population performed once every 10 years, also called a decennial census. It is the responsibility of the United States Census Bureau and is used to determine allocation of congressional seats, allocation of federal assistance, and realignment of the boundaries of legislative districts within states. Correctly managing the census leads to billions of dollars in savings, improved service to the public, and strengthened confidence and trust in government.

Reports from the U.S. Government Accountability Office (GAO) and other sources suggest that the 2010 census represents a high-risk area that has been misman- aged for years. The bureau botched implementation of the Field Data Collection Automation (FDCA) program, an effort to integrate handheld electronic devices into the census data collection process. The handhelds were intended to replace the millions of paper forms and maps that census workers carried when going door to door to collect household data. Paper-based methods for collect- ing and recording data made gathering census informa- tion time-consuming and difficult to organize.

The FDCA program is intended to assist with the initial step of the process: the collection of respondent information. The goal of the program is to implement handheld devices that make census participation as simple as signing for a package. The result would be reduced costs, improved data quality, and better collection efficiency. In 2006, the bureau contracted with Harris Corporation for $595.7 million to oversee the implementation of these mobile computing devices. Harris develops communications products for government and commercial customers worldwide, including wireless transmission equipment. As of this writing, the handhelds have been far too slow and report data too inconsistently to be used reliably for the 2010 census.

Lack of executive oversight is more common in the federal sector as opposed to the private sector, because there are more incentives in the private sector for execu- tives to perform. Federal projects such as the FDCA pro- ject can suffer from lack of accountability for the same reason. The federal government doesn’t use certified pro- gram managers and highly qualified executives for these kinds of projects, and they didn’t for the FDCA program.

The FDCA suffered from poor communication and appropriate testing procedures. For example, the project team did not specify the testing process to measure performance of handheld devices. It also did not accurately describe the technical requirements of the

IS B

N 1-

25 6-

42 91

3- 9

414 Part IV: Building and Managing Systems

project, lack of a risk management process, and ineffective management oversight as factors potentially damaging to the project. The most prominent example of the inadequacy of the project’s risk management is that the performance problems with the handhelds had been reported to project management, but were not identified as a risk going forward. In 2007, GAO reported that changes in system requirements made after the fact were the primary cause for scheduling delays and budget overruns. GAO’s 2008 report reiterated its earlier recommendations and emphasized the importance of quickly implementing them in time for the 2010 census, if possible.

The most crucial area in which the bureau fell short with the FDCA program were in its risk management activities. During testing in 2007, field operatives had reported the mobile devices’ slow speeds in processing addresses in large assignment areas, their tendency to fail while transmitting data to the central data processing center, and other associated bugs and flaws. However, the bureau had no procedures in place to record those observations as potential risks and handle them accordingly. The risks related to mobile handheld performance were not documented.

Also, the bureau has not yet determined a method of measuring the handhelds’ performance. The FDCA contract described a “control panel” application that would easily record and display the performance of handhelds on the Web, accessible via any computer with Internet connectivity. That application has not been developed. Without the ability to accurately measure device performance, it is impossible for the FDCA to verify that the devices are ready for the 2010 census. The large variation in performance specifications submitted to the contract or upon initiation of the con- tract and the additional specifications added after the fact also attest to the lack of a process for measuring ade- quate handheld performance. The report also notes that there were no processes for sharing risks and suggesting appropriate solutions to bureau executives.

While the bureau agreed with the majority of the report’s recommendations, it often argued that the contractor was to blame for a portion of the failings of the project thus far. For example, it claimed that Harris

was responsible for the risks associated with the handhelds, and that its initial contract estimate was inaccurate. Regardless, the bureau admits that it committed many crucial management errors with the FDCA project.

Despite Harris’s role in mismanaging the project, the company was not penalized for its performance. A March 2009 report by the U.S. Department of Commerce Office of the Inspector General noted that “award fees were excessive and not supported by techni- cal assessments of Harris’s performance.” The project had not adequately defined criteria for good performance or established any measurable goals that could be used to reward excellent performance. Harris received 93 percent ($3.2 million) and 91 percent ($11 million) of available fees during the early phases of the project, despite serious performance problems noted by the Census Bureau’s technical reviewers.

Taxpayers will now bear the brunt of the FDCA’s mismanagement, and the bureau will need to wait another 10 years for the 2020 census for another opportunity to revamp the way the U.S. Census is done.

Sources: U.S. Department of Commerce, Office of Audit and Evaluation, “Census 2010: Revised Field Data Collection Automation Contract Incorporated OIG Recommendations, But Concerns Remain Over Fee Awarded During Negotiations,” Field Report No. CAR 18702, March 2009; Jean Thilmany, “Don’t Count on It,” CIO Insight, May 2008; and U.S. Government Accountability Office, “Significant Problems of Critical Automation Contribute to Risks Facing 2010 Census,” March 5, 2008.

Case Study Questions 1. How important is the FDCA project for the U.S.

Census Bureau? How does it impact decision making and operational activities?

2. Evaluate the risks of the FDCA project and key risk factors.

3. Classify and describe the problems the Census Bureau faced in implementing its new wireless data collection system. What people, organization, and technology factors caused these problems?

4. Describe the steps you would have taken to control the risk in this project.

5. If you were in charge of managing this project, what else would you have done differently to increase chances for success?

IS B

N 1-256-42913-9

blog11

Get help from top-rated tutors in any subject.