There seems to be a bit of confusion regarding what ALM (Application Lifecycle Management) is and isn't. First of all, unless you create single one-off utilities, you need ALM. Just because, “Management” is in the name, doesn't mean ALM is for managers. ALM simply recognises that there are phases to development of an application, even informally. What we are trying to do with ALM, is to simply provide tools whereby you can be just as productive in all phases in the production of software as you are in the development phase. ALM's goal is also to not get in the way and force a whole shift in your process in order for it to become useful.
Personally, I feel that one's approach to ALM should be gradual while at the same time intentional. Probably, the most common starting point in any ALM solution rollout would be to implement some form of source code control and archiving. If you're idea of source code control is to copy your files to another machine or simply spool them off to a backup, then you are in need of a good archiving and configuration management tool. Even if you are using a tool to provide these services, it may be worth your while to at least investigate StarTeam. StarTeam is more that just a source code management tool. It is an entry point into several broader areas of ALM. Entry level requirements management, defect/change request tracking, tasks lists, which are all parts of the ALM story.
Many of the smaller consultant folks may scoff at the idea of the use of such a seemingly large tool to handle all these tasks. However, even in these cases, clearly defined requirements are an absolute must. Tracking defect and change requests in a formal manner is also something that every consultant or consultant shop needs to do as well. Post-it notes, and text files are hard to track globally and don't scale very well.