Objectives

Develop experience in working with a team.

Review real world problems, and

identify elements of decision-making,

analyze the problem and its various elements,

describe the theories used to address the problem(s) presented, and

utilize readings and class discussions to date to provide feedback for future improvements (i.e., the manner in which problem(s) have been approached differently to achieve better results).

Description

The class will be divided into groups (maximum 4 people). Each group will be responsible for discussing, reviewing, and presenting a case study. Each group will choose a case study available in the textbook. Groups will sign up on a first come, first serve basis and each group must review a different case.

Materials Required

Brown, C. V., DeHayes, D. W., Hoffer, J. A., Martin, W. E., & Perkins, W. C. (2012). Managing information technology (7th ed.). Don Mills, Canada: Pearson Education.

Instructions

Team Presentation

Due no later than 11:00 p.m. on Sunday of Unit 7 or as directed by your professor

Discussion - each group will discuss the following questions:

What are the most interesting points presented in the case study and why?

What are some of the challenges presented and how can they be mitigated?

Is change positive or negative for the organization? Why?

2. Submit a summary of the conclusions arrived at by the group for each of the three questions. This will be posted no later than the due date for the PowerPoint section (below) to the Team Case Analysis Project: Team Presentation submission box.

3. PowerPoint - each team will prepare materials for a PowerPoint presentation. The presentation will be uploaded to the Team Case Analysis Project: Team Presentation submission box, and will have the following sections:

Introduction - Short summary of the case study. This section will include a background of the case study, in point format, which will give the audience a picture of what this case study is all about (use Notes to provide greater detail).

Challenges - Provide for a brief description of the challenges that the company is facing and how they are planning to address them. This section will provide the audience with a picture of how the company is planning to address some of the challenges. Also, please provide a summary of your group discussions in terms of addressing these same challenges.

Change and Change Management - Provide a summary of your group discussions on change, and whether change is positive or negative for the organization and why.

Recommendations - Based on your group discussions, please discuss what you would you have done differently and why.

Conclusion - Please discuss the lessons learned and the key messages that you would like the audience to take away.

NOTE: Teams are encouraged to be creative in presenting their findings and conclusions.

Team Report

Due no later than 11:00 p.m. on Sunday of Unit 11 or as directed by your professor

Each team will prepare a formal report. This report will expand on the presentation. Just like the presentation, the case study report will include the following sections:

Introduction - Short summary of the case study. This section will include a background of the case study, which will give the audience a picture of what this case study is all about.

Challenges - Provide for a brief description of the challenges that the company is facing and how they are planning to address them. This section will provide the audience with a picture of how the company is planning to address some of the challenges. Also, please provide a summary of your group discussions in terms of addressing these same challenges.

Change and Change Management - Provide a summary of your group discussions on change, and whether change is positive or negative for the organization and why.

Recommendations - Based on your group discussions, please discuss what would you have done differently and why.

Conclusion - Please discuss the lessons learned and the key messages that you would like the audience to take away.

Submit your report to the Team Case Analysis Project: Team Report submission box.

why did you choose this topic

CASE STUDY III-1 Managing a Systems Development Project at Consumer and Industrial Products, Inc. companywide emphasis on total quality management (TQM). Anderson recalls: Late Friday afternoon, T. N. (Ted) Anderson, director of disbursements for Consumer and Industrial Products, Inc. (CIPI), sat staring out the wide window of his 12th-floor corner office, but his mind was elsewhere. Anderson was thinking about the tragic accident that had nearly killed Linda Watkins, project director for the Payables Audit Systems (PAS) development project. Thursday night, when she was on her way home from a movie, a drunken driver had hit her car head on. She would survive, but it would be months before she would be back to work. The PAS system was a critical component of a group of interrelated systems intended to support fundamental changes in how billing and accounts payable at CIPI were handled. Without Watkins, it was in deep trouble. Deeply committed to the success of these new approaches, Anderson did not know exactly what he could do, but he knew he had to take drastic action. He picked up his phone and told his secretary, "Please get me an appointment with IS Director Charles Bunke for the first thing Monday morning." Anderson would have the weekend to decide what to do. In late 1991 we began to look at what we were doing, how we were doing it, the costs involved, and the value we were adding to the company. We real- ized that, even with our computer systems, we were very labor-intensive, and that there ought to be things we could do to increase our productivity and our value added. So we decided to completely rethink what we were currently doing and how we were doing it. Since we were a part of the procurement process, we needed to understand that total process and where accounts payable fit into it. We found that procurement was a three-part process-purchasing the goods, receiving them, and finally paying for them. And we concluded that our role was pretty extensive for someone who was just supposed to be paying the bills. We were spending a lot of effort try- ing to match purchase orders with receiving reports and invoices to make sure that everyone else had done their job properly. We typically had about 15,000 suspended items that we were holding up pay- ment on because of some question that arose in our examination of these three pieces of information. Many of these items spent 30 to 60 days in suspen- sion before we got them corrected, and the vast majority of the problems were not the vendor's fault but rather the result of mistakes within CIPI. For some of our small vendors for whom we were a dom- inant customer, this could result in severe cash flow problems, and even bankruptcy. With today's empha- sis upon strategic partnerships with our vendors, this was intolerable. We finally recognized that the fundamental responsibility for procurement rests with purchas- ing, and once they have ordered the goods, the next thing that is needed is some proof that the goods were received, and we are outside that process also. The Origin of the PAS Project Consumer and Industrial Products, Inc., is a Fortune 100 manufacturer of a large variety of well-known products for both individuals and industry. Headquartered in the United States, CIPI is an international company with facilities in Europe, Asia, and North and South America. The PAS project was one of several interrelated projects that resulted from a fundamental reevaluation of CIPI's accounts payable process as part of CIPI's Copyright 2000 (revised) by Professor E. W. Martin. No part of this case study may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the permission of the author. This case was prepared by Professor Martin as the basis for class discussion rather than to illustrate either effective or ineffective handling of an administrative situation. Its development was supported by the Institute for Research on the Management of Information Systems (IRMIS) of the Indiana University Kelley School of Business. 432 Case Study III-1 Managing a Systems Development Project at Consumer and Industrial Products, Inc. 433 We concluded that our role was to pay the resulting route it from one computer system to another, and bills, and that we should not be holding the other keep track of what has been done to the document. departments' hands to make sure that their process- This will radically change the way we do business in es did not break down. And we certainly should not the department. Things that used to take 18 steps, be placing unfair burdens upon our vendors. going from one clerk to another, will take only 1 or So we decided to make some fundamental 2 steps because all the required information will be changes in what we did and how we did it. We told available through the computer. Not only will this the people in our organization what we wanted to do improve our service, but it will drastically reduce our and why we wanted to do it and gave them the charge processing costs. It will also require that all of our to make the necessary changes. After about 9 months processing systems be integrated with the Document we discovered that we were getting nowhereit was Control System. just not moving. Obviously we could not just top- down it and get the results we wanted. With the help In addition to developing the new Document of a consultant we went back to the drawing board Control System, this new accounts payable approach and studied how to drive this thing from the ground required CIPI to replace or extensively modify five major up rather than from the top down. We discovered that systems: the Freight Audit System (FAST); the our people were very provincialthey saw every- Computerized Invoice Matching System (CIMS), which thing in terms of accounts payable and had little per- audited invoices; the Corporate Approval System (CAS), spective on the overall procurement process. We had which checked that vouchers were approved by author- to change this mind-set, so we spent almost a year ized persons; the vendor database mentioned above; and putting our people through training courses designed the system that dealt with transactions that were not on to expand their perspective. computer-generated purchase orders. The PAS project Our mind-set in accounts payable changed so was originally intended to modify the CIMS system. that we began to get a lot of ideas and a lot of change coming from the floor. There began to be a lot of challenging of what was going on and many sugges- Systems Development at CIPI tions for how we could reach our strategic vision. In cooperation with the other departments involved, the Systems development at CIPI is both centralized and accounts payable people decided to make some fun- decentralized. There is a large corporate IS group that has damental changes in their role and operations. responsibility for corporate databases and systems. Also, Instead of thoroughly investigating each discrep- there are about 30 divisional systems groups. A division ancy, no matter how insignificant, before paying the may develop systems on its own, but if a corporate data- bill, we decided to go ahead and pay all invoices that base is affected, then corporate IS must be involved in the are within a reasonable tolerance. We will adopt a development Corporate IS also sells services to the divi- quality control approach and keep a history of all sions. For example, corporate IS will contract to manage transactions for each vendor so that we can evaluate a project and/or to provide all or some of the technical the vendor's performance over time and eliminate staff for a project, and the time of these people will be vendors that cause significant problems. Not only billed to the division at standard hourly rates. will this result in a significant reduction in work that Similarly, computer operations are both centralized is not adding much value, but it will also provide and decentralized. There is a corporate data center operated much better service to our vendors. by corporate IS, but there are also computers and LANs that We also decided to install a PC-based docu- are operated by the divisions and even by departments. ment imaging system and move toward a paperless Corporate IS sets standards for this hardware and the LANs, environment. We are developing a Document and will contract to provide technical support for the LANs. Control System (DCS) through which most docu- Because the accounts payable systems affected corpo- ments that come into our mail room will be identi- rate financial databases, Anderson had to involve corporate fied, indexed, and entered through document readers IS in the development of most of these systems. The into the imaging system. Then the documents them- Document Control System (DCS), however, did not directly selves will be filed and their images will be placed affect corporate databases, so Anderson decided to use his into the appropriate processing queues for the work own systems group to develop this imaging system. that they require. The Document Control System Corporate IS had just begun using a structured devel- will allow someone to add notes to the document, opment methodology called Stradis. This methodology 434 Part III. Acquiring Information Systems divides the development into eight phases: initial study, detailed study, draft requirements study, outline physical design, total requirements statement, system design, cod- ing and testing, and installation. This methodology pro- vides detailed documentation of what should be done in each phase. At the end of each phase detailed planning of the next phase is done, and cost and time estimates for the remainder of the project are revised. Each phase produces a document that must be approved by both user and IS management before proceeding with the next phase. Stradis also includes a post-implementation review per- formed several months after the system has been installed. treasurer. He made steady progress up the CIPI manage- ment ladder. In the Stradis methodology the executive sponsor has budgetary responsibility and must approve all of the expenditures of the project. He or she must sign off at the end of each phase and authorize the team to proceed with the next phase. According to Watkins, Anderson was a very active executive sponsor: Roles in the PAS Project The Stradis methodology defined a number of roles to be filled in a development project: Anderson was the execu- tive sponsor, Peter Shaw was the project manager, and Linda Watkins was the project director. (Exhibit 1 shows the Disbursements Department organization chart, and Exhibit 2 shows how Corporate IS Systems Development is organized.) Ted was determined that this project would produce a quality system and get done on time and that his peo- ple would commit themselves to the project. He not only talked about these priorities, but he also led by example by attending working sessions where lower- level people were being interviewed and participating in data modeling sessions. By visibly spending a lot of his personal time on the project, he showed his people that it was important for them to spend their time. "The area manager has to take an active role in the development of systems, Anderson asserts: Executive Sponsor Ted Anderson, director of disbursements, is responsible for all CIPI disbursements, including both payroll and accounts payable. Starting with CIPI in 1966 in the gen- eral accounting area, Anderson had a long history of working as the user-manager on systems development projects, including projects in payroll, human resources, and accounting. He spent a year doing acquisitions work for CIPI and in 1978 served a stint in Europe as area particularly when you are trying to reengineer the processes. If you do not have leadership from the manager to set the vision of where you are going, your people tend to automate what they have been doing rather than concentrating on what really adds value and eliminating everything else, so I took a fairly active role in this project. I wanted to make sure that we were staying on track with our vision and on schedule with the project. Disbursements Ted Anderson, Director Payroll Accounts Payable Disbursements Systems Group Tom Hill, Manager Supervisor Supervisor Supervisor Peter Shaw Supervisor EXHIBIT 1 Partial Organization Chart of Disbursements Department Case Study III-1 Managing a Systems Development Project at Consumer and Industrial Products, Inc. 435 Corporate IS Charles Bunke, Director Data Center Systems Development Planning and Technical Services Sales and Marketing Systems Financial Systems Clark Mason Manager Manufacturing Systems Payroll Systems Disbursement Systems Henry Carter, Supervisor Accounts Receivable Systems PAS Project Linda Watkins, Director EXHIBIT 2 Partial Organization Chart of Corporate IS responsible for its success. Shaw also served in the role of business analyst on this project. User Project Manager Peter Shaw was the user project manager. He had worked for CIPI for 18 years, starting as a part-time employee working nights while going to college. Over his career he had worked in payroll, accounting, and human resources, spending part of the time in systems work and part in supervisory positions. For the past 3 years, he had been a supervisor in accounts payable. The user project manager is responsible for making sure that the system meets the user department's business needs and that the system is completed on time. He or she manages the user department effort on the project, making sure that the proper people are identified and made avail- able as needed. He or she is also responsible for represent- ing the user view whenever issues arise and for making sure that any political problems are recognized and dealt with. The user project manager and the project director work closely together to manage the project and are jointly Project Director Linda Watkins, senior analyst in the corporate IS depart- ment, was the project director. Watkins, who had recently joined CIPI, had an MBA in MIS and 7 years of experi- ence as an analyst and project manager with a Fortune 500 company and a financial software consultant. She had experience using Stradis to manage projects, which was one of the reasons she had been hired by CIPI. Because they were being charged for her time, Watkins viewed the disbursement department managers as clients for whom she was working as a consultant. The project director was responsible for managing the IS people on the project. "My job resembled that of the general contractor on a construction project who has to deal with all the subcontractors and manage the budget and Carter had been responsible for maintenance of the Disbursement Department's systems for many years. When the new development projects were initiated, Carter became responsible for them also, but he had little experience with systems development and was of little help to Watkins. Carter reported to Clark Mason, IS manager of finan- cial systems, who was aware of some of Carter's limitations but who valued him for his knowledge of the existing systems. To compensate for Carter's weaknesses, Mason had tried to get the best available project managers, and he told them to come directly to him when they had strategic questions or problems with client relationships. 436 Part III Acquiring Information Systems schedule," Watkins explains. She developed the project plans, determined what each phase would cost, managed the budget, involved the necessary technical people at the right time, and worked through Shaw to make sure that the proper client people were available when needed to be interviewed or make decisions. "I felt like I was ultimately responsible for the suc- cess of the project," Watkins reports, because if things fell apart I would be the one that would take the blame, both from IS management and client management. Therefore my major concern was to look ahead and foresee problems and make sure that they were solved before they impacted the success of the project." "That is what I look for in a project manager," Ted Anderson asserts. "Most of the day-to-day work just hap- pens if you have good people, but the crucial thing is to anticipate potential problems so that you are preventing them rather than just reacting." Watkins also tried to make her clients aware of what was possible with computer technology so that they would not simply automate what they had been doing. "I tried to help them think about why they were doing things instead of just how they were doing them," Watkins says. "Because I was not an expert in accounts payable, I could ask the dumb question that might lead to a new perspective." Another important part of Watkins' job was commu- nication. "I tried to make sure that the client managers knew what was going on at all times and that they knew all the options when there were decisions to be made. I trusted them to make the right decisions if they had the informa- tion they needed." Anderson found that to be a refreshing change from his past experience. "Previously IS has not told its customers any more than it had to. But Linda was very open and we felt that we could trust her." That trust was very important to Watkins, for her ultimate responsibility was to ensure that everyone worked together effectively on the project. She devoted a lot of effort to selecting technical people who had good communications skills and could interact positively with her clients. Steering Group The steering group was chaired by Anderson and included three accounts payable supervisors whose areas were affected by the project, Shaw, and the manager of the dis- bursements systems group, Tom Hill. Watkins and Carter were ex officio members of this group. The role of the steering group was to approve budgets, determine the business direction of the project, and make any necessary decisions. The steering group met on alternate Wednesdays at 3:30 p.m. The agenda and a project status report, such as the one prepared for the steering group meeting on October 6, 1993 (see Exhibit 3), were distributed at least 24 hours before each meeting. Under the "Recap Hours/Dollars" section, the "Original" column refers to the original plan, and the "Forecast" column gives the current estimated hours and cost. The "Variance column is the original plan minus the current estimate, whereas the "Actual-to-Date" column shows the hours and cost incurred up to October 5. A major function of the steering group was to deal with problems and issues. Problems require immediate atten- tion, and issues are potential problems that will move up to the problem category if they are not dealt with. At the start of each steering group meeting, Anderson would ask whether or not everyone had made themselves available when they were needed, and if not he would talk to them afterward. According to Watkins, "Ted was very vocal with his opinions, but he was not autocratic. When there were differences of opinion within the steering group, he would subtly hint at the direction he wanted to go, but it was still up to the interested parties to work out their own resolution of the problem. On the other hand, if he thought the project was getting off the track, he would put his foot down hard!" Shaw was knowledgeable about the political climate, and he and Watkins would meet to plan the steering group meetings. They would discuss the issues that might come up and decide who would present them and how. If there were significant decisions to be made, Watkins and Shaw would discuss them with Anderson ahead of time to see IS Management Henry Carter, IS supervisor of disbursements systems, was Watkins' supervisor. He was responsible for integrating all projects in the disbursements area and for allocating IS people to these projects. His role included advising and coaching the project directors, reviewing their project plans, and making sure that they got the technical assis- tance they needed from the IS organization. The interviews for this case were conducted while Watkins was recovering from her accident, a few months after the events described. Case Study III-I Managing a Systems Development Project at Consumer and Industrial Products, Inc. 437 Recap Hours/Dollars Original Forecast Variance Actual-to-Date 448 434 142 10/8 Initial Study: Hours 577 129 Dollars $20,000 17.000 3.000 16,667 Detailed Study: Hours 1,350 1,337 13 1,165 Dollars $45,000 47,927 -2.927 42,050 Total: Hours 1.927 1,785 1.599 Dollars $65,000 64,927 73 58,717 Milestone Dates Original Revised Completed Complete Context DFDCurrent 8/3 8/4 Complete Level 0 DFD-Current 8/6 8/13 Complete Level 1 DFD-Current 8/22 9/12 9/14 Complete Level O DFD-Proposed 9/17 9/21 9/21 Map System Enhancements to DFD 9/17 9/21 9/24 Complete Data Model (key-based) 10/2 10/11 Complete Detailed Study Report 10/15 Accomplishments This Week: Project Team: Completed the documentation library for the current system. Lucy Robbins: Completed the PAS system's Business & System Objectives. Documented the PAS system's constraints. Started compiling the Detailed Study Report (DSR). Completed the documentation library for the current system. Arnold Johnson: Completed the documentation library for the current system. Linda Watkins: Reviewed the estimates and work plan for the three enhancements. Drafted the authorization for the enhancements. Initiated the Draft Requirements Statement (DRS) work plan. Peter Shaw: Identified the new system's Business & System Objectives. Carol Hemminger and Paul Brown: Completed the documentation of the workshop findings. Refined the ERM diagram. Plans for Next Week: Finish and distribute the draft DSR Finish the data modeling workshop documentation. Complete the DRS work plan. Distribute the finalized Initial Study Report (ISR). Problems That May Affect the Project Status: 1. The DSR will not be finalized until the documentation from the data modeling workshops is completed 2. Two walkthroughs are still outstanding, the key-based data model workshop and current system task force. Both will be completed when client schedules allow. Issues: 1. Due to delays in scheduling interviews with AP, Robbins' time has not been utilized as well as possible. If this continues it may cause delays. EXHIBIT 3 PAS Project Status Report as of October 5, 1993 438 Part III . Acquiring Information Systems where he stood and work out an alternative that he could support. Watkins did not try to force a recommendation on the committee; rather, she presented the problems in busi- ness terms along with a number of possible alternatives. Because the agenda was well organized and all the infor- mation was in the hands of participants ahead of time, the steering group meetings were quite effective, usually end- ing before the scheduled hour was up. Several of the steering group members were the sponsors of other projects, and after the PAS steering group meetings were finished, they would stay around and discuss these projects and their departmental prob- lems with Watkins. She was pleased that she was viewed as a Disbursements Department colleague and not as an outsider. person assigned to the task I would get a cost esti- mate for each task and add them all up to get a total cost for the phase. Again I would go over this with experienced project managers, and with Peter and Ted, before making final adjustments. Then I could start scheduling the tasks. I always included the tasks assigned to user department people, although I did not need them for controlling my budget and many other project managers did not bother with them. I wanted Peter and Ted and their people to see where they fit into the project and how their activities impacted the project schedule. To help with the scheduling, Watkins used a tool called Project Manager's Workbench that included a PERT module and a Gantt Chart module. With the possibility of time con- straints and different staffing levels, she often had to develop several different schedules, for discussion with Shaw and Anderson and for presentation to the steering group. Project Planning The Stradis methodology requires that the project director estimate two costs at the end of each phase of the project: the cost of completing the rest of the project and the cost of the next phase. At the beginning, estimating the cost of the proj- ect was mostly a matter of judgment and experience. Watkins looked at it from several perspectives. First, she con- sidered projects in her past experience that were of similar size and complexity and used their costs to estimate what the PAS system would cost. Then she broke the PAS project down into its phases, did her best to estimate each phase, and totaled up these costs. When she compared these two esti- mates, they came out to be pretty close. Finally, she went over the project and her reasoning with several experienced project managers whose judgment she respected. This initial estimate was not too meaningful, however, because the scope of the project changed radically during the early stages. Estimating the cost of the next phase requires that the project director plan that phase in detail, and then that plan is used to set the budget and to control the project. According to Watkins: Staffing the Project In addition to Watkins, Arnold Johnson was assigned to the project at the beginning. Johnson had worked for Carter as a maintenance programmer for many years. Carter valued him highly as a maintenance programmer and therefore only assigned about 20 percent of Johnson's time to the PAS project. According to Watkins: Arnold did not see any urgency in anything he did, and being primarily assigned to maintenance, he never had any commitment to our deadlines, and he would not even warn me when he was going to miss a deadline. When you are on a project plan that has tasks that have to be done by specific times, every person must be fully committed to the project, so the project plan was always in flux if we depended on him to get anything done. Johnson had a detailed knowledge of the existing CIMS system, and Watkins had planned for him to docu- ment the logical flow of the 14,000 lines of spaghetti code in the main program of the CIMS system. Watkins reported: The Stradis methodology provides an outline of all the steps that you go through to produce the deliver- ables of a stage. I would go through each step and break it down into activities and then break down each activity into tasks that I could assign to people. I would estimate the time that would be required for each task, consider the riskiness of that task, and multiply my estimate by a suitable factor to take the uncertainty into account. I would also ask the people who were assigned the task what kind of effort they felt it would require and would consult with experi- enced people in the IS area. Finally, by multiplying my final time estimate by the hourly rate for the He knew where things were done in the existing program, but he never knew why they were being done. He would never write anything down, so the only way to get information from him was verbally. We eventually decided that the only way to use him on the project was as a consultant and that we would have an analyst interview him to document the existing system. Case Study III-1 . Managing a Systems Development Project at Consumer and Industrial Products, Inc. 439 The project got excellent part-time help from data- base specialists in the CIPI IS department. Watkins recalls: A few weeks after the start of the project, Watkins obtained Lucy Robbins from a contractor firm to be her lead analyst. Robbins had managed a maintenance area at a medium-sized company and had also led a good-sized development project. She could program, but her main strength was in supervising programmers and communi- cating with the technical specialists in IS. Watkins was able to delegate much of the day-to-day supervision to Robbins so that she could concentrate on the strategic aspects of the project, The Stradis methodology required the use of a CASE tool, and Robbins became the CASE tool "gate- keeper" who made sure that the critical project information stored therein was not corrupted. She said, We used IS database people to facilitate data model- ing workshops and to do the modeling. We also used a data analyst to find a logical attribute in the current databases or set it up in the data dictionary if it was new. There were also database administrators who worked with the data modelers to translate the logi- cal data model into physical databases that were optimized to make sure we could get the response time we needed. Watkins also used consultants from the IS develop- mental methodologies group: We used the CASE tool to keep our logical data dictionary, data flow diagrams, and entity/relation- ship data models. The CASE tool keeps your data repository, and then uses that repository to popu- late your data flows, data stores, and entity/rela- tionship models. It also assists in balancing the diagrams to make sure that everything that goes into a diagram is necessary, and everything that is necessary goes in. Because my supervisor was not experienced in development, I used people from the methodolo- gies group to look at my project plans and see if they were reasonable. We also used people from this group as facilitators for meetings and to mod- erate walkthroughs, where not being a member of the team can be a real advantage. Also, when we needed to have a major technical review, the methodologies group would advise me on who should be in attendance. Because IS had far more projects under way than it had good people to staff them, Watkins was never able to convince Henry Carter or Clark Mason to assign a quali- fied CIPI person to the project full time, so she had to staff the project with temporary employees from outside contractors: Carrying out the Project The project began in mid-June 1993 as the CIMS Replacement Project. The Computerized Invoice Matching System (CIMS) was an old, patched-up system that matched invoices to computer-issued purchase orders and receiving reports, paid those invoices where everything agreed, and suspended payment on invoices where there was disagreement After I determined what resources I could get from CIPI, I would look at the tasks the project team had to perform and then try to find the best persons I could that fit our needs. I took as much care hir- ing a contractor as I would in hiring a permanent CIPI person. I tried to get people who were overqualified and keep them challenged by dele- gating as much responsibility to them as they could take. My people had to have excellent tech- nical skills, but I was also concerned that their per- sonalities fit in well with the team and with our clients. The Initial Study Because of strategic changes in how the department intended to operate in the future, a number of significant changes to the system were necessary. The project team concluded that it was impractical to modify the CIMS sys- tem to include several of these important enhancements. Therefore, Shaw and Watkins recommended that a new system be developed instead of attempting to enhance the existing CIMS system. They also suggested that the scope of this system be increased to include manual purchase orders and some transactions that did not involve purchase orders, which effectively collapsed two of the planned development projects into one. At its meeting on August 8, 1993, the steering group accepted this recommendation Watkins hired two contractor analysts who had skills that the team lacked. One was a very good analyst who had experience with CIPI's standard programming language and database management system and had been a liaison with the database people on several projects. The second contractor analyst had a lot of experience in testing 440 Part III . Acquiring Information Systems and authorized the team to base the Initial Study Report on the development of a new system that they named the Payables Audit System (PAS). The Initial Study Report was a high-level presenta- tion of the business objectives of the new system and how this system would further those business objectives. A sev- enteen-page document released on September 21, 1993, it discussed two major problems with the old system and de- scribed five major improvements that the new system would provide. The estimated yearly savings were $85,000 in personnel costs and $50,000 in system maintenance, for a total of $135,000. On October 9, 1993, the Initial Study Report was approved by Anderson, and the team was authorized to proceed with the Detailed Study. to the IBM mainframe hardware platform; and that it must interface with six systems (Purchase Order Control, Supplier Master, Front-End Document Control, Electronic Data Interchange, Corporate Approval, and Payment). Four of these systems were under development at that time, and it was recognized that alternative data sources might need to be temporarily incorporated into PAS. The estimated savings from the new system remained at $135,000 per year, and the cost of developing the system was estimated to be between $250,000 and $350,000. It was estimated that the next phase of the proj- ect would require 1,250 hours over 2.5 months and cost $40,000. The Detailed Study Report was approved on October 31, 1993, and the team was authorized to proceed with the Draft Requirements Study. The Draft Requirements Study As the Draft Requirements Study began, Watkins was con- cerned about three risks that might affect the PAS project. The Detailed Study Report The Detailed Study Report begins with an investigation of the current system, and with production of level 1 and level 2 data flow diagrams and an entity/relationship diagram of the existing system. Then, given the business objectives of the new system, the project team considers how the current system can be improved and prepares data flow diagrams and entity/relationship diagrams for the proposed system. Much work on the Detailed Study Report had been done before it was formally authorized, and this report was issued on October 26, 1993. This report was a 30-page document, with another 55 pages of attachments. The major activities in this stage were initial data modeling workshops whose results were stored in the CASE tool logical data dictionary. Most of the attachments to the Detailed Study Report were printouts of data from this logical data dictionary providing information on the data flow diagrams and the entity/relationship models that were included in the report. The body of this report was mainly an elaboration of the Initial Study Report. It included the following business objectives of the new system: Reduce the cost of voucher processing over the next 3 years to less than the current cost. Reduce the staff required for processing vouchers by 50 percent over the next five years. Significantly reduce the time required to pay vouchers. Provide systematic information for the purpose of measuring quality of vendor and accounts payable performance. Support systematic integration with transportation/ logistics, purchasing, and accounts payable to better facilitate changes due to shifts in business procedures. Among the constraints on the PAS system cited in the Detailed Study Report were that it must be operational no later than September 30, 1994; that it would be limited First, so many interrelated systems were changing at the same time that our requirements were a moving target. In particular, the imaging Document Control System that was our major interface had not been physically implemented and the technology was completely new to CIPI. Second, the schedule called for three other new systems to be installed at the same time as PAS, and conversion and testing would take so much user time that there simply are not enough hours in the day for the accounts payable people to get that done. Finally, I was the only full-time person from the CIPI IS department. Although the contractors were excellent people, they would go away after the project was over and there would be little carryover within CIPI. Watkins discussed her concerns with Carter and Mason and with Anderson and the steering group. They all told her that, at least for the present, the project must pro- ceed as scheduled. The Draft Requirements Study produces detailed information on the inputs, outputs, processes, and data of the new system. In addition to producing level 3 data flow diagrams, the project team describes each process and pro- duces data definitions for the data flows and data stores in these data flow diagrams, and describes the data content (though not the format) of all input and output screens and reports of the new system. The project team was involved in much interviewing and conducted a number of detailed data-modeling workshops to produce this detail. 440 Part III . Acquiring Information Systems and authorized the team to base the Initial Study Report on the development of a new system that they named the Payables Audit System (PAS). The Initial Study Report was a high-level presenta- tion of the business objectives of the new system and how this system would further those business objectives. A sev- enteen-page document released on September 21, 1993, it discussed two major problems with the old system and de- scribed five major improvements that the new system would provide. The estimated yearly savings were $85,000 in personnel costs and $50,000 in system maintenance, for a total of $135,000. On October 9, 1993, the Initial Study Report was approved by Anderson, and the team was authorized to proceed with the Detailed Study. to the IBM mainframe hardware platform; and that it must interface with six systems (Purchase Order Control, Supplier Master, Front-End Document Control, Electronic Data Interchange, Corporate Approval, and Payment). Four of these systems were under development at that time, and it was recognized that alternative data sources might need to be temporarily incorporated into PAS. The estimated savings from the new system remained at $135,000 per year, and the cost of developing the system was estimated to be between $250,000 and $350,000. It was estimated that the next phase of the proj- ect would require 1,250 hours over 2.5 months and cost $40,000. The Detailed Study Report was approved on October 31, 1993, and the team was authorized to proceed with the Draft Requirements Study. The Draft Requirements Study As the Draft Requirements Study began, Watkins was con- cerned about three risks that might affect the PAS project. The Detailed Study Report The Detailed Study Report begins with an investigation of the current system, and with production of level 1 and level 2 data flow diagrams and an entity/relationship diagram of the existing system. Then, given the business objectives of the new system, the project team considers how the current system can be improved and prepares data flow diagrams and entity/relationship diagrams for the proposed system. Much work on the Detailed Study Report had been done before it was formally authorized, and this report was issued on October 26, 1993. This report was a 30-page document, with another 55 pages of attachments. The major activities in this stage were initial data modeling workshops whose results were stored in the CASE tool logical data dictionary. Most of the attachments to the Detailed Study Report were printouts of data from this logical data dictionary providing information on the data flow diagrams and the entity/relationship models that were included in the report. The body of this report was mainly an elaboration of the Initial Study Report. It included the following business objectives of the new system: Reduce the cost of voucher processing over the next 3 years to less than the current cost. Reduce the staff required for processing vouchers by 50 percent over the next five years. Significantly reduce the time required to pay vouchers. Provide systematic information for the purpose of measuring quality of vendor and accounts payable performance. Support systematic integration with transportation/ logistics, purchasing, and accounts payable to better facilitate changes due to shifts in business procedures. Among the constraints on the PAS system cited in the Detailed Study Report were that it must be operational no later than September 30, 1994; that it would be limited First, so many interrelated systems were changing at the same time that our requirements were a moving target. In particular, the imaging Document Control System that was our major interface had not been physically implemented and the technology was completely new to CIPI. Second, the schedule called for three other new systems to be installed at the same time as PAS, and conversion and testing would take so much user time that there simply are not enough hours in the day for the accounts payable people to get that done. Finally, I was the only full-time person from the CIPI IS department. Although the contractors were excellent people, they would go away after the project was over and there would be little carryover within CIPL. Watkins discussed her concerns with Carter and Mason and with Anderson and the steering group. They all told her that, at least for the present, the project must pro- ceed as scheduled. The Draft Requirements Study produces detailed information on the inputs, outputs, processes, and data of the new system. In addition to producing level 3 data flow diagrams, the project team describes each process and pro- duces data definitions for the data flows and data stores in these data flow diagrams, and describes the data content (though not the format) of all input and output screens and reports of the new system. The project team was involved in much interviewing and conducted a number of detailed data-modeling workshops to produce this detail. Case Study III-1 . Managing a Systems Development Project at Consumer and Industrial Products, Inc. 441 Document Control System, the technical people decided to move as much of the PAS system to the LAN as possible. This was a radical change that increased the estimated development cost substantially. Watkins' new estimate of the total cost of the PAS system was $560,000. This was a substantial increase from the previous estimate of $250,000 to $350,000, and it caused some concern in CIPI management. Peter Shaw asserted: The major problem encountered was the inability to schedule activities with Disbursements Department people when they were needed. For example, in early December, Anderson came to Watkins and told her that his people would be fully occupied with year-end closing activities for the last 2 weeks of December and the first 2 weeks of January and that they would not be available for work on the PAS project. He was very unhappy with this situation and apologized for delaying the project. Watkins told him that she understood that the business came first and that she would reschedule activities and do what she could to reduce the impact on the schedule. This potential problem had been brought up at the steering group meeting in early November, but the group had decided to go ahead with the planned schedule. The PAS Draft Requirements Statement (DRS) was completed on March 21, 1994, 4 weeks behind schedule, but only $5,000 over budget. The DRS filled two thick loose-leaf binders with detailed documentation of the processes and the data content of the inputs, outputs, data flows, and data stores in the new system. Preparation of the Outline Physical Design was projected to require 600 hours over 6 weeks at a cost of $25,000. The DRS was approved on April 3, 1994, and the Outline Physical Design phase was begun. The company treasurer doesn't care a bit about the PAS project. All he cares about is how many dollars are going to be spent and in which year. When the cost went up so that we were substantially over budget for this year, that got his attention. If the increase were for next year it would not be a major problem because he would have time to plan for it- to get it into his budget. But this year his budget is set, so Linda and I have to figure out how we can stay within our budget and still get a usable system this year as version 1 and upgrade it to what we really need next year. On June 27, just as the Outline Physical Design report was being completed, Watkins' car accident occurred, tak- ing her away from work for several months. Anderson's Concerns The Outline Physical Design In the Outline Physical Design phase the IS technical peo- ple become involved for the first time. They look at the logical system and consider alternatives as to how it can be implemented with hardware and new manual proce- dures. The approach in this phase is to map the processes in the logical data flow diagrams and the data models to manual processes and hardware and to make sure that this proposed hardware can be supplied and supported by the organization. Programming languages and utilities are also considered, so at the end of this phase the project team knows what kind of programming specifications and technical capabilities will be required. The PAS system was originally planned to run on the IBM mainframe, but given the use of a LAN for the Watkins' accident focused Anderson's attention on some long-standing concerns. He was worried because among the directors of the five projects he was sponsoring, Watkins was the best. All of his other projects were behind schedule and in trouble, and now he did not know what would happen to the PAS project. Anderson was fully committed to his strategic direc- tion for the disbursements area, and he felt that his repu- tation would be at risk if the systems necessary to support his planned changes could not be completed successfully. He was convinced that he had to take decisive action to get things back on track. He needed a plan of attack to present to IS Director Charles Bunke at tomorrow's meeting