Is it still called iterative, when you're treating it like a project

People have gotten used to working in projects, with a defined start and a definitive end. You would start off by deciding what to do, how to do it, and then plan accordingly. At the end of the project the results would be known, and given to the client. The client would then be happy... hopefully.

However it is more likely that as the project progresses, you will find that the desired results will not be met. Or that the client has changed his mind, or that the market environment has changed. Anyway it means your project has to face a tough schedule to still make the original deadline.

The promise of iterative project frameworks is that you will be able to act earlier on such changes. You have a mandate to change course and replan each iteration, because the project is scheduled as such.

And still these kinds of projects (or at least projects which are presumed to be of this kind) can fail to the very same problems iterative frameworks are supposed to solve. I've found these failures to have some common characteristics:

• Iterations are handled as if they were small, individual projects. Instead of having one big problem, people make several small ones. That in itself is not an issue, but...
• No feedback and no interaction between iterations means that a failure in one iteration reverberates in subsequent ones. There's no learning curve, because each iteration is self-contained.
• The client of a project is hardly involved in the iteration at all. Just at the very end. It places higher importance on the end of each iteration to meet its requirements each and every single time. What you end up with, is just a series of deadlines of similar status as if you would have one big deadline at the end of a non-iterative project.
• The organization, the company that the project is contained in, is not flexible enough to deal with the changes after each iteration. Sometimes people, tools, hardware and software need to shift each time. If the acquisition cycle for these is longer than the iteration itself, an iterative project framework will always fail.

As far as I can see people have difficulties understanding projects in the first place, let alone shifting mindsets to iterative working. It is a definite sea change, and people would just rather fall back into things they know (or think they know). That's why people make the same mistakes all over again, even when they think they're trying something new.