MT300 Unit 6 Implementation Seminar Reflection Example

Who Chose July? An MT300 Unit 6 Seminar Reflection on Hershey's 1999 Go-Live and a Rental Company's Launch Date

[Student Name]

Purdue University Global

MT300: Management of Information Systems

Unit 6 Seminar Reflection

[Instructor Name]

[Date]

The seminar discussion and Larkfield Event Rentals are composite; the Hershey case and sources cited are real.

The Case in Four Sentences

In July 1999, Hershey Foods brought new enterprise software for order processing, planning and customer management into use across its operations (Stedman, 1999). In the following months, during the period when retailers stock up for Halloween, orders and shipments failed and some customers did not receive the products they had ordered. The company reported weaker quarterly results and attributed part of the shortfall to the new systems. The software was later stabilized and used successfully.

What the Seminar Did With It

Discussion opened where I expected, on software quality: whether the packages were ready and whether the integration had been tested. Then a classmate pointed out that the same systems eventually ran well, which meant software quality alone could not explain the failure. That left two explanations still standing: timing and testing. Markus et al. (2000), studying firms that adopted enterprise systems, found that problems at go-live often came from the conditions of the cutover, compressed schedules and reduced testing, rather than from the software itself, and the seminar's discussion moved in the same direction.

The Question About July

Our instructor's question changed the discussion: who chose July? Until then, I had treated the go-live date as a fact about the project, like the software's name. The question reframed it as a choice that someone made and could have made differently. Choosing a date just before the busiest season meant that any problem would surface exactly when the company had the least room to absorb it. Laudon and Laudon (2022) describe implementation as an organizational change, not a technical event, and a change scheduled into peak demand carries a price that does not appear in any project budget.

A go-live date is a management decision with a price, and the price is paid in the season you choose.

What Changed in My Thinking

Before the seminar, I would have described a failed launch by looking for the faulty part: a bug, a bad interface, a vendor that overpromised. That approach still has value, but it misses decisions that sit outside the software. The calendar is one of them. Who is trained, how much testing happens and whether the old system stays available are others. Each is a management choice, and each can turn a manageable problem into a crisis. I now think of a go-live as a bet placed on a particular date, and the size of the bet depends on what the business has to do in the weeks that follow.

I also noticed how quickly the room, including me, assumed that a large company with a large budget must have had a technical problem. The classmate's point about the software working later was a small fact, but it removed the easiest explanation and made the harder one visible. It was a reminder that the most useful contribution to a discussion is sometimes a single fact that rules something out, and that I should look for those facts before settling on a story about why something failed.

Larkfield's May, Set Beside It

Larkfield's owner has proposed launching the new rental platform in May. The reasoning is sensible: new seasonal crew are hired in spring anyway, so they could learn the new tablets from their first day rather than learning the paper system and then switching. I take that argument seriously. But Larkfield's season looks a lot like Hershey's, with roughly 70 percent of its events booked from late spring to mid-autumn. A May launch would put newly hired crews on unfamiliar tablets in the busiest weeks, with the office learning a new order system while forty events go out on a Saturday. In the Unit 3 business case, a February launch paid back in seven months and a July launch in ten; May would sit close to July, because the learning period would overlap the peak.

What I Would Ask Before Any Cutover

The seminar changed what I think a project plan has to answer. Before any launch, I would now ask three questions. First, what happens to the first day's orders if the new system is wrong, and is there a way to serve them from the old one? Second, who has the authority to stop the launch, and on what evidence? Third, which season is the company entering, and could the same work be done in a quieter one? For Larkfield, those questions point to February.

References

Laudon, K. C., & Laudon, J. P. (2022). Management information systems: Managing the digital firm (17th ed.). Pearson.

Markus, M. L., Axline, S., Petrie, D., & Tanis, C. (2000). Learning from adopters' experiences with ERP: Problems encountered and success achieved. Journal of Information Technology, 15(4), 245-265. https://doi.org/10.1080/02683960010008944

Stedman, C. (1999, November 1). Failed ERP gamble haunts Hershey. Computerworld.