The point of the server certificate is so that the client can make sure that it knows the correct, genuine public key for the server. Certificates signed by a CA are one way to achieve that (with the unspoken assumption that we trust the CA for signing only certificates with correct information in it, and not goofing it up). A self-signed certificate cannot convey such a guarantee.
However, in some cases, you can replace the certificate model with direct trust. Namely, you inform your Web browser that for a given, specific certificate can be trusted. Firefox describes that as a "security exception". This does not completely solves the issue, but at least it reduces it to the problem of making sure once that you are seeing the correct server certificate. Afterwards, your browser will remember that "exception" and won't bug you with scary warnings -- but it will glower like a drunk christmas tree if somebody tries to feed you another, distinct self-signed certificate.
For the initial registration, when you connect the first time to the server, have your browser display the "SHA-1 fingerprint" or "thumbprint". How it is named changes with the browser, but this is a SHA-1 hash value computed over the complete certificate, and expressed as 40 hexadecimal characters. Then, phone the sysadmin of the intended server and have him spell out the thumbprint of his certificate: if they match, then you know that your browser is seeing the right certificate, and can register it as a locally known security exception.
(The process described above is exactly what is done for SSH, and it works for SSL too.)
How to install a "security exception" depends on the browser and the operating system, and I am way too lazy to lookup and describe all the possible combinations. But, at least, you have the concept.