I know of an excellent project that was spun up in a hurry to write a small amount of really tough code and roll it out. It was a “quick win” project, so named because you can get value out the door quickly.
I say “was” for two reasons.
One: the quick part is over. It is going into production. Now comes the really slow part: owning it.
Two: the Win part is over too. It’s value has been demonstrated. It reduced cost or increased capability as expected.
The problem with a “‘quick win” project is that code, quickly written, requires quick replacement.
Now that this code is in production, it is time to purchase a commercial package, for less money, and greater capability, to augment it. The alternative is to slowly, expensively, add one feature after another until the IT group has written so much code that they will hold on out of pride, even though a commercial package is (a) available, (b) less expensive, and (c) more fully featured.
You see, if you invest in a quick win, you have to settle for the quick replacement that follows. Otherwise, you are taking a success and letting it sink into failure.