Most people only know one way to run a project; they use a structure that in software development is called a "waterfall model." In a waterfall model, each stage of the project is finished in order, and the results enable the next stage, until you are finished.
For instance, in writing a term paper for school, you might choose a topic, gather some references about the topic, read them while taking notes or making notecards, produce an outline for your intended paper, write a first draft, and then produce a final paper. I think this is the basic process we were all taught in school, and sometimes teachers would even make you turn in intermediate steps just to make sure you were using the process.
An "iterative" model is a different way of doing things, and I think for some types of projects it is superior. In an iterative model, rather than finishing an entire stage before moving onto the next, you divide your project into iterations. At the finish of each iteration, you will have done some of all of the appropriate kinds of work, and ideally you will have some kind of product.
If you applied an iterative model to writing a term paper, your first iteration might result in a very rudimentary draft. You would have gathered only a few sources and skimmed them, produced a very sketchy outline, and put together the bare bones of the paper. The goal should be to end up with a crappy paper at the end of this first iteration. From having done the work so far, you should now know what kind of sources you need and want, and have a good idea where the paper is going. The next cycle will incorporate more sources and be much more complete, and will result in the next draft. You can continue this process of refinement indefinitely (or until the paper is due).
I'm only sketching this out in a very basic way, but there are a few obvious advantages of using an iterative model. First, as soon as you've finished the first iteration, you are always ready to turn in something. Even that horrible first draft can probably get you some grade. In software development, this makes even more sense - even a very "sketchy" program that runs allows people to see visible progress.
Second, you learn a lot during each iteration. When your users or clients see the sketchy program, they will be filled with ideas about what it should do, or you may learn that it wasn't what they wanted after all. Even writing an extremely rough draft of a paper often gives you a very good idea of how it should proceed.
Third, an iterative model prevents the major drawback of a waterfall model - that you may never finish a stage to your satisfaction. If you have to have the whole paper planned out before you begin, you might not get there. If you can't hammer out a complete set of requirements for your software project, you could lose weeks or months or even years that you could have been making progress on other fronts.
Ed taught a computer science class last semester, and many of his students turned in a final project that didn't run. I can't help but think some of them would have been helped by using an iterative model (as well as starting earlier and all of the other usual student tricks). It's better to turn in the 2nd generation code that runs than to turn in the niftier 3rd generation code that doesn't. Using an iterative model lets you hedge your bets this way - at nearly every stage you've produced something of value.