Probably the easiest way is to start with your problems. Do you have more information on this?
Are the TNG servers unstable, or is it a problem with the agents / access , or are you just not getting the information that you require?

The general (non technical) pitfalls are:
Too much information. If you are new to the product then you can get lost with the amount of crap information that NSM gathers.
Start with the basics.Don't go off and discover all devices on your entire network. Start small with a couple of servers and with simple monitoring.
All these Components. Even if you just have the base product it is easy to get lost with all the different components. So remember what the objective is - to get alerted to problems. So to start with forget about Workload, Security, problem and file management, performance, and portal. Don't bother making the worldview look nice or getting the GCU to work. Stick with the core function and make sure the agents are reporting to the event console.
Here's a normal scenario. Yesterday you were a Unix SA, then your company bought Unicenter, today you have been told you are also in charge of Enterprise Management. This happens all the time. If your company has spent hundreds of thousands on software then they need to be prepared to spend a few thousand more on resources and training. You need someone dedicated to the product, not doing it as a bit part of their other job.

There is no technical problem with the product that cannot be resolved. There are limitations, but without knowing more specifics about your implementation I could not comment.

Of course the biggest problem with the product is always: CA sell a Unicenter bundle half of which is not needed or ever used, (usually involving AMO, SDO, RCO, Service Desk, and Unicenter), whack it all on a couple of servers using their fast-track rollout and bugger off with the cash.

Please let us know what tech issues you are having.

The biggest problem my predecessors had was with SNMP.  My understanding is that CA has community strings hard-coded in the product which wreaks havoc when trying to alter the default 'public' password for managed objects.  Certain admin procedures appear to overwrite localized community strings in the COR and break SNMP.  I've also been told that there is no translation of vendor MIB sysobjids forcing the UC admin to do get this information from vendor (some like Cisco won't release that information) and configuring it manually.  If there is any truth to this the road ahead is long, difficult and filled with pot holes.

What version of TNG/NSM are you going to use? If you're not sure of the version go to a command prompt (assuming Windows) and type UNIVER.

As to the community strings, in the recent revisions of TNG/NSM, community strings can be changed in the pollset browser by running the POLLSETS command.

As to the translation of traps, the current version of the product does do "automatic" trap translation, and provides the ability to import traps into the trap database.

But unfortunately as firmware/software/IOS versions changes, so do the syntax of the traps they send out.