When to Throw Up the Stop Sign, Revisited

Stop gap measures are short term actions taken to cross a gap, to lurch through a specific situation until normal or better conditions are reached. Stop gap measures are often done on the expectation of a near term return to the old normal. Yet there are risks and costs often forgotten in the rush to keep throwing out one more rope to reach the other side. There are times to throw up a stop sign on the stop gap measures.

When to Stop with the Stop Gaps

Stop gap measures can be short term low cost measures to avoid a big expense. Yet stop gap measures can be costly by keeping obsolete systems running and avoiding a transition that is necessary. Review the cost of small fixes over the recent past and into the short term future. If these continual costs added up make the large expense (new server hardware, new computer, updated software licenses) a reasonable ROI, go and make the change.
Endless short term fixes are often compared to the cost of doing nothing with an obsolete system. The sunk cost is often considered more important than the sometimes lesser cost of starting on a new and supported application. Run the numbers without factoring in the sunk costs. If you wouldn’t keep the current system going due to its current heavy financial or support load, stop the short term fixes and make the long term change.

When to Stop Waiting for the Big Bills to Hit

Sometimes waiting and delaying large expenses saves money. Delaying can also add to costs. Stop gap measures to avoid the large cost of a migration often ignore the cost that system migrations become more expensive as more files, data vaults, user accounts and roles are added to a legacy system. Review the growing cost of migration and change due to the foot-dragging on legacy systems.
An addendum to this is avoiding the ongoing costs that skyrocket when the application provider says “We don’t support that anymore.” You could pay ten times as much in ongoing support costs for what they don’t support, in addition to much higher costs for getting the vendor’s help in migrating it later when they are pouring their resources into developer the product two or three versions later than the one you are running on.
Don’t neglect the added cost and hassle of adding functions or features to an existing database which cause you to mutate further from the product’s baseline, making migration to a subsequent version more difficult.

When to Give Up on a Project

One of the long neglected areas that we forget to put a stop to are the projects that seem to linger on and on. A project to improve system up-time may mutate through three different proposals before sitting on a back burner, reported on but never acted upon. Five minutes per meeting for ten people for a year is hours of productive time lost doing nothing about the issue. And refusing to give up on a long neglected project but studying new ways of doing it may neglect higher priorities that need attention and solutions today.