This case was prepared by Ralph Westfall. It is intended to serve as a basis for educational discussion, rather than to illustrate effective or ineffective handling of a management situation.
* with apologies to Arthur C. Clarke and Stanley Kubrick
The Property Management Division at Mega Financial, a diversified financial services corporation, was experiencing increasing difficulties in managing its growing inventory of branch and administrative space. Manual methods, which were adequate when the corporation was much smaller, could not handle the higher levels of real estate activity resulting from growth and from organizational restructuring as Mega attempted to adapt its operations to a deregulated financial environment.
In the early 1980's the Property Management Division developed a strategic plan for increasing the effectiveness and bottom-line contribution of the property management function. Automation of a large proportion of the operational and record-keeping activities in the Division was a major objective of this plan.
Mega Financial Corporation is one of the thirty largest financial service companies in the United States. Assets of the firm have been growing steadily through internal expansion and acquisitions, and earnings have increased almost every year over the past decade. The company is generally recognized as well-managed, and was coping successfully with the challenges during the 1980's of deregulation of the financial service industries, increasing competition both from within the industry and from non-financial companies entering this sector, and higher loan losses due to turmoil in the national and world economies
Mega Financial has over 300 offices and administratively facilities in its home territory and several hundred locations, generally operated by subsidiaries, in other parts of the country. Approximately half of these properties are owned, with the rest leased or ground-leased. Most properties acquired in recent years are leased. Lately some owned properties have been sold and leased-back in order to realize capital gains resulting from the substantial inflation in real estate values over the past two decades.
Mega's decentralized data processing philosophy encourages organizational units to internally program or externally contract for the computer software that they need. Over 20 software packages are available for this purpose on a large mainframe IBM timesharing computer. These include database management systems, statistical packages, decision support/modeling systems, programming languages, graphics software and hardware, word processors, communications packages, etc. Personal computers are also available and their usage is extensively supported. Managers are encouraged to send staff members to internal and external training courses to learn to use these resources so they can develop and maintain software used in their work areas.
Mega's real estate holdings are managed by its Property Management Division. This function is relatively centralized: the Division has responsibility for property acquisition and disposition, realty accounting, management of surplus space that has been leased to outside tenants, property maintenance. and various related activities.
Although the volume of activity rose dramatically over the years due to internal growth and a more turbulent environment, relatively few of the functions in the Property Management Division were automated by the early 1980's. Manual methods, which were adequate for a smaller organization in a less dynamic environment, were still being used. Lease renewals were monitored via 3 X 5 "tickler" cards; the firm missed an opportunity to renew one lease on very favorable terms because it had not given notice by the latest date specified in the lease.
There was an abundance of paper files, but the material was not well organized or readily accessible. Most of the rent calculations and other activities were performed with "10-key" adding machines. Automated sources of data from other departments were accessed only on a manual basis, in the form of bulky paper printouts or microfiche. Charges sent from this Division into the company's internal accounting system were in the form of handwritten input sheets that were subsequently keypunched onto magnetic tape in another Division.
Clerical and analytical personnel in the Division were generally dissatisfied with the current situation and claimed to be interested in the potential benefits of automation. However they were skeptical about the capabilities of computerized systems to accommodate the complexities of how they actually performed their jobs.
Managers in the Property Management Division were not happy with the manual systems that being used. There were substantial backlogs in many of the operational activities assigned to their staff. One key clerical employee, with many years of experience, was about to retire and there did not appear to be any potential replacements with comparable experience or interest in the job.
It was very difficult for the Division to respond to requests from senior management for information about Mega's real estate holdings because the source data was dispersed among hundreds of files scattered throughout the Division. The corporation was also experiencing difficulties in controlling vacant space, since organizational units were not penalized for abandoning space before the leases expired.
Recognizing the magnitude of the problems associated with current operations, Mega's Property Management Division conducted an internal study of the benefits of automation. This was subsequently supplemented with analyses by outside consultants, resulting in a strategic plan for computerization of many of the activities within the Division. Titled "The Space Database Plan," this document identified potential benefits of increased accuracy and higher productivity in existing functions. It also anticipated more effective management of Mega's current and future space requirements through analyses and projections that would be impractical under the current mode of operation.
Based on this strategic plan, Jovian Configuration Consultants, Ltd. (JCCL) was hired to help produce a request-for-proposal (RFP) for software which could accomplish this automation. Three Division personnel, who became available in a recent corporate reorganization at Mega, were assigned to work with JCCL. One of these persons had some experience in programming small decision support systems in BASIC, and another had a degree in Urban Planning. None of the three was particularly familiar with many of the operational functions in the Division.
Over a six-month period, this project team and Jovian Configuration Consultants, Ltd. developed an RFP for the proposed system. Initial discussions focused on a series of output reports that JCCL previously created based on work with other clients, or planned to use in a generic automated real estate management system that it was developing at the time. Internal documents and reports from the Property Management Division were brought into these discussions. The final specifications in the request-for-proposal a synthesis of JCCL's proposed report formats and these internal documents.
JCCL personnel interviewed most of the managers and some of the operational personnel in the Property Management Division. However to a large extent they relied on Mega's three-person project team to collect information and to research, issues related to operational activities.
Many Divisions at Mega had long been using ACCOMMODATOR (Accurate Modern Data Organizer) database management software on Mega's mainframe timesharing computer. This database package was specified in the RFP to be the basis for the Space Database because it was expected that the previous experience at Mega would facilitate maintenance of the proposed system. However recognizing that ACCOMMODATOR's input screen component was severely limited, the RFP suggested that a third-party product--which was in general usage at Mega--should be used to handle inputs to the Space Database.
Toward the end of the year, Division management began to exert pressure to finish the RFP. There were funds in the current budget for software development, but they might not be available if the contract was not awarded before year end. The RFP was completed relatively quickly and ended up as a very bulky, not well-organized document. It contained a great deal of documentation on the proposed output reports and the structure of the supporting database. There were also tentative formats for input, screens and menus, but there was virtually no information on operational usage or how the system would integrate with current activities and operational personnel.
Bids on the specified system were solicited from approximately ten organizations, including Mega's own data processing Division. The majority decided not to bid on the project. Several firms offered to provide their existing systems, customizing them where necessary, as an alternative to the proposed software. Jovian Configuration Consultants, Ltd. submitted a bid in excess of $500,000 for the system as specified, but suggested that Mega might be better off reducing the scope of the proposal or waiting until JCCL's generic system was completed. Another consultant--"Discovery One" Software & Systems (D.O.S.S)--offered to handle the project for $250, 000.
The Property Management Division engaged in serious discussions with both JCCL and D.O.S.S, exploring ways the scope of the proposal could be reduced to cut the total cost. D.O.S.S's references were also checked but little information was obtained:--one contact said D.O.S.S did some work for his company about five years before, but he did not remember much about them. Eventually D.O.S.S was awarded a contract for $200,000 to produce a scaled-down version of the proposed system and represented to provide some additional services that D.O.S.S said would be necessary for a successful implementation.
"Discovery One" Software & Systems conducted an intensive analysis of the specifications in the RFP and prepared a schedule for development of the Space Database. A number of visual charts, which showed the relationship of the various modules and their data elements, were produced and reviewed with Mega's project team. D.O.S.S personnel expressed dissatisfaction with the RFP---that it did not provide adequate information for many aspects of the project--but said they would be able to cope with these problems. A schedule and Gantt charts were also produced for the various tasks that would need to be completed.
Following these initial meetings, D.O.S.S began development of the system. Meetings were conducted each month; to review the progress of their activities. At each meeting D.O.S.S reported that the project was on schedule and the scheduled tasks were completed, but nothing tangible was ever provided to document these assertions. Mega paid the previously agreed-upon progress payments to D.O.S.S after each meeting.
At the end of summer, D.O.S.S announced that the system was completed on schedule. Along with the project team, a senior manager from the Property Management Division visited D.O.S.S's office for a "walk-through." D.were O.S.S staff provided a tour of the facilities, pointed out the extensive internal documentation that they had generated, and discussed workings of the Space Database. An attempt was made to operate the system but, due to an unusually heavy load on Mega's timesharing computer that day, it was not possible to demonstrate many of its functions.
One member of Mega's project team was assigned to perform testing in the one-month "acceptance period." Given this time limitation, the testing concentrated on the aspects of the system that were most crucial to property Management Division operations, or that would be used most frequently. This testing revealed a substantial number of flaws in the system, and showed that some features did not function at all. The team considered refusing to accept the system, but decided to "sign-off" based on D.O.S.S's fervent assurances that the problems would be fixed in the subsequent three-month warranty period.
Additional testing continued through the end of the year. Many of the reported problems were fixed to Mega' s satisfaction. However it frequently occurred that D.O.S.S claimed certain problems were corrected, but subsequent testing indicated those aspects of the system still did not function correctly, or at all. For other problems, D.O.S.S responded that the particular aspect was consistent with the RFP specifications and quoted costs of several thousand dollars for each of the required "change orders."
By this time some of the major problems were corrected. D.O.S.S was awarded another contract, providing for twelve months of maintenance and for additional services that D.O.S.S insisted were necessary for a successful operational implementation.
Mega's project team decided to implement the system on an incremental basis. The initial phase loaded the database with information on leases where Mega was the lessee. The project team collected information from internal files, researched discrepancies and missing items, and filled out the input sheets that were provided with the system. The person who currently handled the corresponding manual function was consulted occasionally, but did not participate in the data collection or data entry due to an existing heavy work load. Data entry was handled by temporary personnel who were hired by the project team. After this phase was completed, ongoing maintenance of this data continued to be performed by the project team.
Data on leases where Mega was the lessor (for outside tenants in surplus space) was the next target. This task was selected because of its similarities to the first phase, and because it was expected to be fairly easy to accomplish. Input forms, and instructions developed by Mega's project team, were sent to the personnel in outlying locations who managed those leases. The completed input forms were again entered into the system by temporary personnel and verified by the project team. No ongoing effort was made to maintain these data, however, since they were not considered to be of major importance and because it was expected they could easily be updated whenever necessary.
The most crucial aspect of the Space Database was the module that tracked space occupancy and internal accounting charges for more than 700 organizational units in over 400 buildings. It was decided to coordinate loading of this data with a re-analysis and updating of this information for the following year's budget since charges in the previous several years were based on an overall percentage increase rather than a complete analysis of each location. Accounting personnel were hired from a temporary employee agency to collect and analyze the required expense and investment data from internal records, and then fill out the input worksheets. These temporary workers were supervised by the staff members who were responsible for the space tracking function. As before, the input forms were loaded into the database by temporary data entry personnel.
Management in the Property Management Division hoped that the Space Database could be used to calculate internal rent charges for the next year on an automated basis. However it took much longer than expected to verify the data, reconcile discrepancies between manual and computerized calculations, and reformat the numerous specialized manual analyses into the database's homogenous structure. As a stop-gap measure, one member of the project team created a reporting system based on a microcomputer spread-sheet package. This interim system contained one file which produced a management report of charges by building for each occupant, and an independent second file which printed out the charges to be keypunched into Mega's internal accounting system.
Relations between Mega and D.O.S.S deteriorated steadily in this period. D.O.S.S kept proposing additional, very expensive services and enhancements to the system, which it claimed were essential to the successful implementation of the Space Database. The senior manager in the Property Management Division expressed serious reservations about additional expenditures for a system that had not fulfilled many of the original expectations. Operational usage of the Space Database, and ongoing testing of other aspects that had not been implemented, continued to reveal problems and failures to match the RFP specifications.
Mega decided to handle further maintenance of the Space Database via internal data processing personnel and/or some other external consultant, so D.O.S.S's contract was not renewed. As an accommodation to D.O.S.S's tax situation the final payment for maintenance and other services was to be mailed in January, even though for budget purposes it was going to be billed to the Property Management Division's internal accounting in the preceding month. These machinations resulted in two checks inadvertently being sent--one in December and one in January-- for the final payment. Instead of returning the duplicate payment, D.O.S.S submitted an invoice for services supposedly performed after the contract expired.
A new manager was assigned to oversee the project at Mega, and she formulated a plan for a "crash effort" to finish the loading and validation of the accounting and space occupancy data in the database. Several staff members were transferred to the project on an interim basis, with temporary agency personnel covering their regular activities for approximately four months. This effort was successful and the system was then used to calculate internal accounting charges for over 700 organizational units for the following year. However most of the data entry for this update was handled by one of the members of the project team because operational personnel were too busy, and because use of the input screens to update the system required a significant technical knowledge of the idiosyncrasies of the Space Database.
Problems with the input screens became more evident at this time. One screen in particular tended to "blow up" when new inputs were followed by updates. Since the third-party developer of the input screen system had subsequently gone out of business, it appeared these screens would eventually need to be replaced with new ones based on the screen manager component of' the ACCOMMODATOR system. (This conversion was subsequently accomplished: some screens were developed by a different consulting firm and others were produced internally by Mega staff.)
D.O.S.S provided a COBOL program to handle internal rent charge calculations for the Space Database. This program functioned only in batch mode, recalculated charges for all locations even if just a few had been updated, and was usually run overnight because it required hours of computer time. Subsequently it was discovered that an upgrade to a later version of ACCOMMODATOR at Mega would make this calculation program incompatible with the database. Therefore a new program was created by Mega personnel, coded entirely within ACCOMMODATOR's "fourth generation" programming language, which performed the same calculations approximately fifteen times faster and could be used for individual locations as well as for the whole database.
Most of the reports programmed by D.O.S.S from the original specifications were never used. However a substantial number of other reports were developed by Mega personnel to provide similar types of information from the data in the Space Database. Some of these new reports were used on a regular basis, while others were developed for special analyses in response to needs within the Property Management Division or in other areas of the corporation.
One of the operational personnel in the Property Management Division
frequently criticized the Space Database and was generally resistant
to the automation effort as it progressed. After it became apparent
that the project was going to continue, that management was not
sympathetic to unconstructive criticism, and that adjustments
in some operational procedures would be required, this person
resigned from Mega.
Location (can be thought of as a street address)
Land
Building
Floor
Tenant
Organization Chart (identifies Tenants)
Lease
Payee (person/entity that receives lease rent or other payments)
Cost
Investment
Chart of Accounts