$200,001 - A Space Database Odyssey *
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
* 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
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.
The Property Management Division
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
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.
Year One - The Space Database Plan
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 were 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
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
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 to provide some additional
services that D.O.S.S said would be necessary for a successful implementation.
Year Two - System Development and Testing
"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.O.S.S staff provided a tour of the
facilities, pointed out the extensive internal documentation that they had generated, and
discussed the 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 the Property Management Division’s 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
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
that certain problems were corrected, but subsequent testing indicated that 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."
Year Three - Implementation and Maintenance
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 that 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.
Year Four - Epilogue
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 that 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.
Suggested Questions for Analysis and Discussion
1. Comment briefly on each of the following aspects of the Space Database project
(advantages or disadvantages, possible alternatives, etc.)
a. the project team
b. systems analysis/information requirements determination activities in
defining specifications for the Space Database
c. traditional systems development life cycle (SDLC) approach that was
used--first producing comprehensive specifications for a large-scale
system, and then generating the system directly from these specifications
d. process used to select the firm (Discovery One Software and Systems) that
programmed the system from the specifications
e. testing process and activities after the Space Database was delivered to
f. system architecture: ACCOMMODATOR database, third-party input
screen system, and an external COBOL program for rent calculations, all
running on a timesharing computer
g. Mega Financial's activities in managing its relationship with the system
h. efforts to implement the Space Database in the Property Management
2. Identify what you would consider to be the three biggest problems associated with
the Space Database project. What would you have done differently in each of