Continuous integration is a way of speeding up software delivery by making sure every change is introduced without breaking the project. Or, another way of looking at it is that when the build is broken the team is notified immediately and is quickly fixed. Many groups look at breaking the build as a bad thing, something for which the offender is punished. Teams that use continuous integration use a build break as a fire alarm; an indication that something has gone wrong that needs immediate attention. This instant feedback is the magic that makes CI so effective.
So is getting a CI tool and pointing it at your project all it takes to get the benefits? Not quite, but it is better than nothing. You also need a robust, reliable build process. If your build gives a lot of false alarms the team won't trust it and won't leap into action when needed. Good, automated tests are another must; without good tests you only know when your project doesn't compile, not when it is actually broken. Note that good tests don't necessarily mean total coverage; high quality tests are always preferred to a simple high coverage metric. Finally, the development process used needs to encourage small incremental changes instead of big-bang commits. If the team only checks-in code occasionally, the benefits of early detection are lost. This last element is often the hardest, as it sometimes requires a change in people on a team, not just tools.