396 Part III • Acquiring Information Systems
The format must follow the outline provided.
The mainframe to which the PC is connected
for this presentation must be an IBM running under
MVS. If your MVS is not exactly like ours (as outlined
in the RFP), you must provide a written explanation of
how the differences (i.e., response time, color, etc.)
affect the demonstration.
The presentation is limited to 2 hours, including
30 minutes for questions at the end. You will be given
30 minutes to set up.
With the data and formulas provided, create a
relational database so that the following Profit and Loss
(P&L) statements can be modeled and reported.Fiscal 2010 Plan:
Item P&L: by month with total year at the right.
Control Unit P&L: by item with total at the right.
Business Unit P&L: by Control Unit with total at the
right.Fiscal 2011 Projection:
Business Unit P&L: by Control Unit with total at the
right.Combined Fiscal 2010 & Fiscal 2011:
Control Unit Change Analysis: by item for total Fiscal
2010 vs. proj. Fiscal 2011.
Business Unit Change Analysis: by Control Unit for
total Fiscal 2010 vs. proj. Fiscal 2011.
Provide a listing of the populated database relations
and/or tables.
Provide an example listing of the programs/models
and report format files for each type of P&L and
Change Analysis above.Presentation DirectionsFIGURE 10.5 Forms for Managing Vendor Demonstrations.
(A) Example of Requirements for Vendor DemonstrationIn addition to evaluating the vendors’ responses
from the formal RFP process, two other types of data
collection are commonly pursued, at least for the leading
candidate packages. First, demonstrations of the leading
packages can usually be arranged. Sometimes it is feasible
for the vendor to set up a demo on-site at your organiza-
tion; at other times, another location is required—either at
a vendor location or at another company that has installed
the package. Detailed requirements for software demos
should be provided to the vendors to ensure equitable
conditions for demonstrating system performance, because
response times and other characteristics of system per-
formance can vary greatly depending on the hardware and
system software being used to run the package. An exam-
ple of demo specifications for a financial modeling
package, and a form for evaluating the demo specified, are
provided in Figures 10.5A and 10.5B. In addition, it may
be possible for the vendor to install the software on an
organization’s computer for some short period to allow for
a test drive of the application. This way you can explore
firsthand some features for which there was not time in
the demo to show and which can be used by your staff to
investigate potential idiosyncrasies that the vendor staff
quickly passed over during the demo.
Second, references from users of the software pack-
age in other companies are usually obtained. Each vendor
might be asked to provide a reference list, to your specifi-
cations, as part of the RFP. You might ask for references
from similar-sized organizations, some geographically
close, who have a mix of experience (e.g., some recent and
some long-term purchasers), or from similar businesses.
You might even want to talk with a reference that chose not
to purchase the package. One especially effective tech-
nique is to require the vendor to provide the names of users
as well as IS specialists for each customer organization on
their reference list. Task force members can then divide up
the names with, for example, IS specialists contacting their
counterparts in companies that have already implemented
the package. Site visits to one or more of these companies
might also be possible. Evaluations of the vendor’s sup-
port, consulting, and training services can also be obtained
from these sources. You need to understand the situation
with the reference organization to understand how to
evaluate their experiences. For example, a reference where
the package was thrust on users by the IT unit will likely
provide different comments than a reference from an
organization in which the package was selected by a care-
ful process, as outlined in this section.
Based on all the previously mentioned information
sources, the project team needs to assess how well the
company’s needs match with the capabilities of the avail-
able packages (see Figure 10.6). This is a critical step that
requires both business and technical expertise. The results
of this process step will also have broad ramifications for
the project’s success.
Once the discrepancies between the package’s capa-
bilities and the company’s needs are identified, the team
needs to choose the best way to deal with these discrepan-
cies for the top candidate packages. Assuming that the
company decides that it still wants to invest in one of these