Knowing when to let a project die

One of the most fortunate aspects of my current job is that I have quite a bit of autonomy in getting things done. We have the usual projects which take priority that are dictated by program or business needs, or are necessary to update existing systems. There is usually some time to squeeze in additional infrastructure projects that benefit the IT side of the house. I tend to focus on ways to improve monitoring and automation.

Since priorities change constantly, some of these internal projects end up on the back burner. They might be experimental in nature, or not have a clear plan, but they exist in some form and can linger for quite a while.

When I first took my current job, I found myself doing quite a bit of cleanup. We had quite a few virtual machines hanging around that didn’t seem to be doing much.

I asked a number of questions such as:

  • Is there an active project in place making use of this VM?
  • If the version of the software seemed old, would restarting the project require completely rebuilding the environment?
  • If we’d have to rebuild the whole thing, would we be better off killing it and starting from scratch if the project comes up again?

I decided to follow my own advice last week, and killed off two projects. I had been looking at Senusu for system monitoring, but it wasn’t an appropriate fit for our environment. I also had been looking at RunDeck for system orchestration, but the need had mostly passed.

The system resources we freed up by dumping these two projects were relatively minor, but formally killing off both of these test systems let me clear it off my to do list. Nothing is stopping us from revisiting either project in the future, but for now, they’re done.