| Course | MGT 505 Managing in an Age of Information Technology Change |
|---|---|
| Module | Module 8 |
| Paper type | MBA IT project recovery plan |
| Length | About 1,010 words, 6 pages |
| Format | APA 7 student paper |
| School | Aspen University |
| Program | Master of Business Administration |
| Updated | October 2026 |
Free sample paper for MGT 505 Module 8
Fourteen Months Late and Ninety Percent Done: Rescuing or Stopping a Food Cooperative's Enterprise System
Student Name
Master of Business Administration, Aspen University
MGT 505: Managing in an Age of Information Technology Change
Instructor Name
Month Day, Year
Fourteen Months Late and Ninety Percent Done: Rescuing or Stopping a Food Cooperative's Enterprise System
North Loop Food Co-op, a composite member-owned grocery cooperative in Minneapolis, Minnesota, operates four stores with about $62 million in sales. Two years ago, its board approved a project to replace aging accounting, purchasing and inventory systems with an enterprise resource planning package, budgeted at $1.4 million and ten months. The project has now run twenty-four months and cost $2.5 million. The stores still use the old systems. The implementation vendor says the work is ninety percent complete and needs four more months and $400,000. Store managers have lost confidence, and two board members want to stop. The general manager has asked for an analysis.
How Projects Escalate
Keil (1995) studied a software project that continued for years despite growing evidence it would fail. He found that managers kept investing for several reasons: money already spent seemed to demand completion, project leaders believed success was close, negative information was filtered as it moved up and admitting failure carried personal and political costs. Keil et al. (2000) surveyed IT auditors about projects they had observed and found that a substantial share showed escalation of commitment, and that escalated projects were far more likely to fail. Factors associated with escalation included sunk costs, the belief that the project was nearly complete and concern for reputation.
Warning Signs at North Loop
| Warning sign | Evidence |
|---|---|
| Repeated "nearly done" claims | Vendor reported 80% complete twelve months ago and 90% now |
| Sunk cost reasoning | Board minutes: "we've invested too much to stop" |
| Filtered bad news | Project lead told staff not to raise problems before board meetings |
| Expanding scope | Member loyalty and online ordering added in month nine |
| Unclear accountability | Vendor, project lead and finance each blame the others |
| No independent review | Only the vendor reports progress |
How Organizations Step Back
Montealegre and Keil (2000) studied how the city of Denver de-escalated its troubled automated baggage system at the new airport. They described four phases: problem recognition, when leaders acknowledge the project is in serious trouble; re-examination of the prior course of action, often with outside help; search for alternatives, such as scaled-down options; and implementing an exit strategy that preserves what can be saved. Denver kept a reduced automated system for one concourse and built a conventional system for the rest, opening the airport.
What the Independent Review Will Ask
The consultant will answer four questions: which modules actually work with the co-op's data today, how much effort remains for each, whether the vendor's team has the skills to finish and whether the co-op's own staff are ready to use the system. The answers, not the vendor's percentage, will drive the decision. Earlier modules' lessons on estimation apply here: the review will produce ranges, broken down by module, compared with how long similar work took on this project so far.
Options
Continuing as planned would spend at least $400,000 more on the vendor's estimate, which history suggests is optimistic. Stopping entirely would write off $2.5 million and leave the co-op on systems near the end of vendor support. A narrowed rescue would complete only accounting and purchasing, which a review suggests are closest to working, and defer inventory, loyalty and online ordering.
Why the Board Kept Going
The board's minutes show the escalation patterns clearly. At month twelve, the project lead reported that the system was nearly ready and that stopping would waste the money spent. At month eighteen, the vendor proposed adding member loyalty and online ordering to show progress, and the board agreed. At no point did anyone outside the project assess its state. Board members later said they had doubts but did not want to undermine the general manager, who had championed the project. Keil's account of how bad news is filtered and how sponsors protect their commitments describes this history closely.
Costs of Each Option
Stopping now writes off the $2.5 million already spent, but that money is gone whatever is decided. The relevant comparison is future costs and benefits. Continuing as planned would cost at least $400,000 and, based on the project's history of 70% overruns, more likely $700,000. The narrowed rescue is estimated at $300,000 for the first release. A hosted accounting package, the fallback, would cost about $180,000 to implement and $60,000 a year. Treating sunk costs as irrelevant is the first step out of escalation.
The Recovery Plan
Following Montealegre and Keil's phases, the board will first acknowledge the problem publicly to staff and pause new work for thirty days. An independent consultant will review the system and the vendor's estimate. Based on that review, the first release will be narrowed to accounting and purchasing, with a fixed price per release, an approach from earlier in the course. The board will set a stop point in advance: if the first release is not live within five months and $300,000, the co-op will stop and choose a hosted accounting package instead. A governance committee will receive the consultant's monthly reports, and staff will be invited to report problems directly.
Leading Through the Pause
Pausing a large project is hard on the people who have worked on it. The general manager will meet the project team to acknowledge their effort and explain that the pause is about the decision, not their competence. Staff from the stores will be invited to the consultant's review sessions, so the people who must use the system help judge whether it works. The board chair will explain the pause to members in the co-op's newsletter, which rebuilds trust by being honest about what went wrong.
Lessons for the Next Project
The co-op will require independent progress reviews on any project above $250,000, estimates with ranges and contracts priced by release.
Conclusion
North Loop's project shows the escalation patterns Keil and colleagues documented: sunk costs, repeated near-completion claims and filtered bad news. Montealegre and Keil's phases provide a path to step back, re-examine and either rescue a narrowed system or exit with a stop point decided before more money is spent.
References
Keil, M. (1995). Pulling the plug: Software project management and the problem of project escalation. MIS Quarterly, 19(4), 421-447. https://doi.org/10.2307/249627
Keil, M., Mann, J., & Rai, A. (2000). Why software projects escalate: An empirical analysis and test of four theoretical models. MIS Quarterly, 24(4), 631-647. https://doi.org/10.2307/3250950
Montealegre, R., & Keil, M. (2000). De-escalating information technology projects: Lessons from the Denver International Airport. MIS Quarterly, 24(3), 417-447. https://doi.org/10.2307/3250968
MGT 505 Module 8 instructions, in plain terms
The final module of Aspen's MGT 505 deals with projects in trouble and asks students to judge whether one should be saved and how. A culminating paper usually reviews a troubled project's history, applies research on escalation and recovery and draws on earlier course topics. Follow the Module 8 directions in your classroom; this example concerns one cooperative's enterprise system. Describe the project's history with figures, including how earlier decisions to continue were made. Explain why organizations keep investing in failing projects. Identify warning signs with evidence from the project's records. Compare options, including stopping. Recommend a plan with clear decision points, drawing on earlier topics such as estimation, vendors and governance.
Inside the MGT 505 Module 8 example
The paper opens with North Loop Food Co-op, which runs four grocery stores and replaced its accounting, purchasing and inventory systems with an enterprise package. The project, budgeted at $1.4 million over ten months, has cost $2.5 million over twenty-four months, and the stores still run old systems. Keil's MIS Quarterly article on pulling the plug describes how project managers and executives escalate commitment. Keil, Mann and Rai's MIS Quarterly study found many IT projects showed escalation and identified factors such as sunk costs and completion effects. Montealegre and Keil's MIS Quarterly article describes de-escalation as problem recognition, re-examination, search for alternatives and implementing an exit strategy. A table lists warning signs, from repeated "nearly done" claims to staff afraid to report problems. The plan pauses new work, commissions an independent review, narrows the first release to accounting and purchasing and sets a stop point.
MGT 505 Module 8 rubric: what earns full marks
Recovery papers are judged on an honest history, accurate use of escalation research, a fair comparison that includes stopping and a plan with decision points. This example shows how the cooperative's choices match patterns Keil and colleagues documented. Montealegre and Keil's phases organize the recovery plan, from public acknowledgment to a stop point set in advance. The warning signs table helps leaders see escalation in their own project. The plan draws on earlier course topics: estimation, vendor contracts and governance, and it compares options using future costs only, setting sunk costs aside.
MGT 505 Module 8 help: mistakes that cost marks
Troubled project papers often recommend pressing on with better management without asking whether the project should continue. Consider stopping as a real option. Use research on escalation to explain why leaders keep investing. Identify warning signs with evidence. Bring in an independent view, since those closest to a project often cannot see it clearly. Set a stop point defined in advance. Draw on earlier course topics, such as estimating and vendor management. Finally, explain what the organization will learn so the next project avoids the same path. Compare options using only future costs.
Write yours, or have the desk draft it
This paper is an original model document written by our desk, not a submitted student paper and not an official Aspen University document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.
More MGT 505 and Master of Business Administration sample papers
- MGT 505 Module 1: The IT Environment and the Manager's Role
- MGT 505 Module 2: IT Department Problems and Symptoms
- MGT 505 Module 3: The Nature of Software Projects
- MGT 505 Module 4: Estimating and Scheduling Technology Work
- MGT 505 Module 5: Managing Technical Professionals
- MGT 505 Module 6: Vendors, Outsourcing and Cloud Services
- MGT 505 Module 7: IT Governance and Alignment
- MGT 530 Module 2: Traits, Skills and Behaviors
- MGT 514 Module 5: Conflict and Difficult Conversations
- MGT 647 Module 1: Agile Values and Fit
- MGT 570 Module 4: Business-Level Strategy
MGT 505 Module 8 questions, answered
What does MGT 505 Module 8 usually ask for?
Aspen's MGT 505 ends with troubled IT projects, so an MBA paper deciding whether to rescue or stop a project, drawing on the course, is typical. Check your classroom prompt.
What is escalation of commitment?
Continuing to invest in a failing course of action, often because of money already spent, optimism or reluctance to admit failure, which Keil and colleagues documented in IT projects.
How do organizations de-escalate a failing project?
Montealegre and Keil described four phases: recognizing the problem, re-examining the project, searching for alternatives and implementing an exit strategy.
Where can I find a free MGT 505 Module 8 sample paper?
The example above decides whether to rescue or stop a food cooperative's late enterprise system and sets out a recovery plan with a stop point.
Should money already spent affect the decision?
No. Sunk costs cannot be recovered, so the decision should depend on future costs and benefits.