Let me zip up my flame suit....there ok much better.
First, you need a domain expert, and the engineers will need to have a very good understanding of what is trying to be achieved. Second, I suggest you get QA or someone who's full time job is related to verification and validation, involved at the beginning. They need to understand the problem as well as the engineers (how else will they write good tests?).
Demand your engineers to validate their code with unit testing before it gets released into a build. Don't let everyone dump their stuff into a single development branch. Reserve a "stable" branch for QA to use, and only add to it when QA is ready to test new features/fixes.
Don't expect anything great from tools that make UML diagrams. Keep the paperwork to a minimum, and only document something if after reading it, an engineer can say "Yeah, that is actually useful for me to know, and it'll help me in 6 months when I come back to this area of the code".
Get your technical writer involved immediately. They need to underatand the problem too, otherwise they'll be nagging your engineers later when they're busy fixing bugs.
The most important thing is to push back as much scope and features as you possibly can. Don't volunteer to prototype or demo anything unless it's demanded. I can't stress enough how these activities distract engineers from getting core functionality completed and tested. Demos tend to need bells and whistles, and they generate new demands that marketing suddenly seems to think is a must have for the first release. Stay focused on the smallest subset of critical functions that you can get away with.
Now here's where I need the flame suit (and I am a developer btw). Every developer should have the exact same environment. Everyone uses the same tools, the same build scripts, etc. Get everyone their own dedicated development box (separate from their R&D and general everyday tasks). Avoid proprietary methods from the start. There will be a lot of whining over IDEs and editors. Tell them to shut it and deal with it. Give them x number of days to decide which tools they need to use, but after that, everyone does it the same way. If you have to bring new people onto the project, it will make things much easier to get them up to speed, and they can get help from any of the team members, not the same guy over and over.
I guess to summarize:
- Minimize scope
- Mandate clear understanding of what is trying to be achieved by all members of the team
- Begin QA activities on day 1
- All developers use the same tools/compilers/etc
- Mandate unit testing before code is released to the QA branch
- Don't release until it's stable (requires yelling at your boss)