I am going to punt a little here and guess that RTM stands for Requirements Traceability Matrix and say, no difference! However, since it is spelled out in all caps like that (RTM), I will also guess that it is probably one group's/organization's/standard's defintion of what a traceability matrix should be.
For me, the primary traceability is Source -> Group -> Requirement -> Test.
I go up from the test in case of questions, clarifications, and prioritization. I trace to a test for 1) a test is a great validator that I have a well stated requirement (a good reason to do test driven development) and 2) to prove the requirment as implmented. The risk factor there is without a trace, you have little to "show" that the requirement was implemented in a sequential project. Agile does "traceability" by demonstrating the completed Story at the end of the iteration.
The basic risk of not doing things well (process, etc.) is rework. That is, we have to do the work over again. Our studies of organziations see well over half of their effort on software development projects is rework of upstream mistakes. Don't do it right the first time you get to do it again.
As for the general stuff, we have a lot of stuff on our commercial site (www.construx.com) and SEI has a lot of that kind of stuff at SEIR (https://seir.sei.cmu.edu/SEIR/).