Yes IMM development does require a "balanced" team for a successful project to be completed. I will not delve into any particular project that I have been involved with, rather I will make these general comments from my experiences.
1. If you are designing a system to be run in a network or multi-user environment do as much of the development and testing in the target environment as possible. Too often performance issues, file locking, access permissions, etc., do not come to light until after implementation. From then on, whatever you do is only patching up. Design these features into the project.
2. Communication at the "concept" stage is most important. Be sure to convey to the "end user" what you understand it is that they want.
3. You usually only get one chance to get something right. If you deliver something that is not quite right, then it really does not matter for a very long time what you do to repair design flaws, fix bugs, etc. The end user's expectations have usually been dashed. It may even be better in some cases to start again rather than overcome the resistance associated with using something that has had bad comments made about it in the past. Students are quite good about passing the word along about things that do not work from term to term: "Oh those sessions were really awful, I wouldn't bother going, if I were you, as the software never worked."
4. Any team software development can really stretch the team's harmony. Do not hold onto what you hold dear too tightly. I can spend many hours designing a form, thinking that it is "just so," admiring the functionality built-in, proud of what I have done, only to have it dashed when someone points out something like: "It looks fine at that resolution, what does it look like at a higher resolution?"
5. Do not get defensive about you own part. Always give people enough space to see the errors of their ways.