Crosby Manufacturing Corporation Case Study
For use by University of Phoenix only. Copyright 2021 © John Wiley & Sons, Inc.
Crosby Manufacturing Corporation
“I’ve called this meeting to resolve a major problem with our management cost and control system
[MCCS],” remarked Wilfred Livingston, president of Crosby Manufacturing Corporation. “We’re having one
hell of a time trying to meet competition with our antiquated MCCS reporting procedures. Last year we
were considered nonresponsive to three large government contracts because we could not adhere to the
customer’s financial reporting requirements. The government has recently shown a renewed interest in
Crosby Manufacturing. If we can computerize our project financial reporting procedure, we’ll be in great
shape to meet the competition head on. The customer might even waive the financial reporting
requirements if we show our immediate intent to convert.”
Crosby Manufacturing was a $250-million-a- year electronics component manufacturing firm in 2005, at
which time Wilfred “Willy” Livingston became president. His first major act was to reorganize the 700
employees into a modified matrix structure. This reorganization was the first step in Livingston’s long-
range plan to obtain large government contracts. The matrix provided the customer focal point policy that
government agencies prefer. After three years, the matrix seemed to be working. Now the company could
begin the second phase, an improved MCCS policy.
On October 20, 2007, Livingston called a meeting with department managers from project management,
cost accounting, management information systems (MIS), data processing, and planning. Livingston: “We
have to replace our current computer with a more advanced model so as to update our MCCS reporting
procedures. In order for us to grow, we’ll have to develop capabilities for keeping two or even three
different sets of books for our customers. Our current computer does not have this capability. We’re
talking about a sizable cash outlay, not necessarily to impress our customers, but to increase our
business base and grow. We need weekly, or even daily, cost data so as to better control our projects.”
MIS manager: “I guess the first step in the design, development, and implementation process would be
the feasibility study. I have prepared a list of the major topics which are normally included in a feasibility
study of this sort.” [See Exhibit I.]
Livingston: “What kind of costs are you considering in the feasibility study?”
MIS manager: “The major cost items include input–output demands; processing; storage capacity; rental,
purchase, or lease of a system; nonrecurring expenditures; recurring expenditures; cost of supplies;
facility requirements; and training requirements. We’ll have to get a lot of this information from the
Electronic data processing (EDP) department.”
EDP manager: “You must remember that, for a short period of time, we’ll end up with two computer
systems in operation at the same time. This cannot be helped. However, I have prepared a typical
(abbreviated) schedule of my own. [See Table I.] You’ll notice from the right-hand column that I’m
somewhat optimistic as to how long it should take us.”
Livingston: “Have we prepared a checklist on how to evaluate a vendor?”
EDP manager: “Besides the benchmark test, I have prepared a list of topics that we must include in
evaluating any vendor. (See Exhibit II.). We should plan to call on or visit other installations that have
purchased the same equipment and see the system in action. Unfortunately, we may have to commit real
early and begin developing software packages. As a matter of fact, using the principle of concurrency, we
should begin developing our software packages right now.
EXHIBIT I. FEASIBILITY STUDY
• Objectives of the study
• Costs
• Benefits
• Manual or computer-based solution?
Crosby Manufacturing Corporation Case Study
Page 2 of 3
For use by University of Phoenix only. Copyright 2021 © John Wiley & Sons, Inc.
• Objectives of the system
• Input requirements
• Output requirements
• Processing requirements
• Preliminary system description
• Evaluation of bids from vendors
• Financial analysis
• Conclusions
TABLE I TYPICAL SCHEDULE (IN MONTHS)
Activity Normal Time to Complete Crash Time to Complete
Management go-ahead 0 0
Release of preliminary system specs. 6 2
Receipt of bids on specs. 2 1
Order hardware and systems software 2 1
Flow charts completed 2 2
Applications programs completed 3 6
Receipt of hardware and systems software 3 3
Testing and debugging done 2 2
Documentation, if required 2 2
Changeover completed 22 15*
* This assumes that some of the activities can be run in parallel, instead of in series.
EXHIBIT II. VENDOR SUPPORT EVALUATION FACTORS
• Availability of hardware and software packages
• Hardware performance, delivery, and past track record
• Vendor proximity and service-and-support record
• Emergency backup procedure
• Availability of applications programs and their compatibility with our other systems
• Capacity for expansion
• Documentation
• Availability of consultants for systems programming and general training
• Who burdens training cost?
• Risk of obsolescence
• Ease of use
Livingston: “Because of the importance of this project, I’m going to violate our normal structure and
appoint Tim Emary from our planning group as project leader. He’s not as knowledgeable as your people
are in regard to computers, but he does know how to lay out a schedule and get the job done. I’m sure
your people will give him all the necessary support he needs. Remember, I’ll be behind this project all the
way. We’re going to convene again one week from today, at which time I expect to see a detailed
schedule with all major milestones, team meetings, design review meetings, et cetera, shown and
identified. I’d like the project to be complete in 18 months, if possible. If there are risks in the schedule,
identify them. Any questions?”
