Okay, it's a bit involved, but here goes.
As you probably know, Java is fully cross-platform (as long as the target platform supports the JVM). However, LWJGL is a Java-OpenGL binding, and OpenGL is not cross-platform. The result is that LWJGL uses system libraries (.DLL files on windows) to manage OpenGL. It has different libraries for Windows, Mac, Linux, and Solaris (though I think we're dropping that one). To run LWJGL, you need to let the JVM have access to those libraries.
There are various ways of doing this with Java Webstart and via Applets, those are covered in tutorials. However, to get the program to run from the desktop itself, you have to do a bit of legwork. There's one magic command you need to utilize, that needs to be called in code before LWJGL is managed:
System.setProperty("org.lwjgl.librarypath", PATH_TO_DIRECTORY_CONTAINING_LIBRARIES);
This tells the JVM that the required libraries for LWJGL to function are contained in the indicated location. Point the JVM to a folder containing all needed files, and LWJGL does the rest.
However, there's still a problem. You need to ensure that the libraries are on the user's computer. A lovely solution would be to package them into a .jar file, and access them from there (it would be amazing if that worked, it really would), but the OS cannot use libraries within archive files (which a JAR is).
What I do is (in my opinion) the next best thing - I package all possible LWJGL libraries into a JAR, then, on program startup, detect which need to be given to the OS. I then use JavaIO to write them to a location on the user's computer, then pass that location to the JVM. The delay caused by this is really not very noticeable, and since all required data stays inside the JAR, the user can delete the archived libraries after each run of the program and everything still works on the next run.
Alternatively, you can run your program by passing the aforementioned library location to the JVM as a command-line argument; however that requires you to mess around with the command line. Not really difficult, but I find the method I mentioned earlier more rigorous (you can manage things in your application itself, and can detect problems and handle them when they occur) and less complicated once it works out (you run it like any other Java program, and never worry again).
Does that all make sense?