GM591 Unit 6 Ending Projects Seminar Reflection Example

Stopping Is Designed, Not Summoned: A Unit 6 Seminar Reflection on Ending Projects

[Student Name]

Purdue University Global

GM591: Strategic Project Selection and Initiation

Unit 6 Seminar Reflection

[Instructor Name]

[Date]

The classmates' organizations and the writer's electric cooperative are composite; the research cited is real.

Two Cases

Two classmates' cases framed the session. Priya works in early research at a drug developer. Every early compound there faces a review every six months against criteria set when the project began: target potency, a safety signal threshold and a cost ceiling for the next stage. Most compounds are stopped. When one is, its team moves to a new compound, and the stopped project does not count against anyone's performance review. Priya said a team that stops a compound early, before it consumes a large budget, is often praised for it.

Gabriel described a state licensing agency where a system replacement ran four years past its original date. Each year the project reported progress, received more funding and set a new date. It ended only when a professional association sued over licensing delays, and a judge's order forced the agency to restore the old system's functions.

My Starting View

I came into the session believing that stopping a failing project takes courage, and that projects run on because leaders lack it. Our cooperative's member portal, which I described in Unit 1, seemed to prove it. The general manager announced it publicly and could not bring himself to stop it.

What the Session Showed

The instructor asked us to compare the two organizations, not the two leaders. At the drug developer, nobody needed courage, because stopping was built into the process. The criteria were written before anyone was attached to the result. Reviews happened on a schedule, not when someone raised a concern. And stopping cost the team nothing in their careers.

At the licensing agency, none of those things existed. There were no exit criteria, so each year's review asked only whether the project was making progress, which it always claimed to be. Barry Staw and Jerry Ross describe how project, psychological, social and organizational forces combine to keep a failing course of action going, and they argue that escalation is often a product of how organizations are structured, not just individual stubbornness (Staw & Ross, 1987). The agency's structure gave every force room to work.

Stopping at the drug developer took no courage because the organization had already decided, in advance, what would end a project and protected the people who ended it.

Isabelle Royer's study of failed projects at two French companies found that what kept them alive was a shared conviction across the organization that they would succeed, and that they ended only when an exit champion, someone willing to push for the evidence that would end the project, emerged (Royer, 2003). The drug developer had institutionalized the exit champion's role in its review criteria. The licensing agency waited for a judge to play it.

Mark Keil applied Staw and Ross's framework to a software project that kept receiving money for years after its problems were widely known inside the company (Keil, 1995). Reading his case, I recognized our portal: the same mix of sunk investment, a sponsor's public commitment and a culture that treated cancellation as failure. None of those forces required anyone to be a coward. They only required that no one be assigned the job of asking whether the project should end, and that no date be set on which the question had to be asked.

Where My View Changed and Where It Held

My view changed on the main point. Stopping a project is mainly a design problem. An organization that sets exit criteria at approval, reviews projects on a schedule and protects the people who end them does not depend on rare courage.

My view held in one respect. Even with criteria, someone has to apply them honestly when the moment comes. Priya admitted that some teams at her company argue for extensions by redefining what the criteria meant. Design reduces the courage needed, but it does not remove it. Criteria written loosely invite exactly that kind of argument, so the wording has to be specific enough that a number either meets it or does not, with a date attached.

The Fiber Pilot's Gate

Our cooperative's fiber broadband pilot faces its gate review in two months. The pilot was approved with a business case but no written exit criteria. I will ask the planning committee to adopt three conditions before the review: a minimum sign-up rate, a ceiling on construction cost per home, and the outcome of the state broadband grant. I will also ask that the finance director, who did not sponsor the project, present the gate analysis, so that the review has someone in Royer's exit champion role who has no stake in the pilot's success.

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

Royer, I. (2003). Why bad projects are so hard to kill. Harvard Business Review, 81(2), 48-56.

Staw, B. M., & Ross, J. (1987). Behavior in escalation situations: Antecedents, prototypes, and solutions. Research in Organizational Behavior, 9, 39-78.