I know the flow, use one myself for one of the biggest corporations out there. But in my experience it's more "This is how we <i>wish</i> to work with clients". I see a lot of "<i>squeezing the agency</i>" going on these days. (As in non-paid extra work and revisions despite agreements on how to work).
I have met these guys in Puerto Rico (which has a great emerging startup scene) a few times. They are by far one of the top UI/Django pairs I have ever met, and could give any agency a run for their money. If you're looking for some smart guys, consider them.
It is great how everyone describes their "process". In the end, it doesn't mean a lot because it will all depend on the mentality and knowledge of the people working in that process.<p>At the point where people are using "the process" and not their brains and common sense, it will cause a disaster and you have to re-invent "the process".
We too employ a 2-iteration process to the design/UI/IA stages, however I don't understand why the client should still have the option to make 2 iterations of changes during the development and especially deployment stages of a project.<p>The elweb illustrated process appears to miss out a key section - functional specification. We derive our func specs from scoping meetings, navigation structure, required content etc. which is then presented to the client along with user journey flow diagrams. This is presented and discussed before the design stage - thus the functionality is agreed upon far before development happens.<p>With this approach we don't run into the situation where the client wants to make changes during development which could potentially greatly extend a project's timescale (cost is less of an issue as it passed onto the client anyway).
We run an Agile process where the client is involved as Product Owner in the team. The client can add stories at any stage, and set the priority in the backlog at any time. They just can't change the current sprint's stories and priorities. That way they can make as many changes as they want, and the impact of those changes are always visible.<p>Why limit the client to an arbitrary number of changes (like 2 in this example?) The whole idea of Agile development is that we cannot know everything in the beginning, so we spec as much as we can in the beginning, and leave room to change our minds at a later stage.<p>Of course, we explain this way of working up front as well, and we make the benefits clear to the client. They have to buy into this before we start with anything. It works very well when they do buy in though.
> We also explain the client that anything that does not get revisions or comments from them is automatically approved.<p>A really good post. I hate it when the clients ask for last minute features (for free) after not saying a thing about this during the development.