Waterfall, RUP, XP... and one process to bring them all, and in the darkness bind them

What happens if you have a big project to execute and your organization mandates Waterfall? Of course, you can try to follow the mandated process, and hope everything goes fine (bad news: chances are not).

As a rule, you must ALWAYS adopt/adapt the process to fit your project (and not the other way around)

A big project will be less risky using RUP, but if you can't convince the outside groups (typically management, QA, overzealous SPEG/SPI group, maybe the customers too) to use it, you can use RUP and make it look like a waterfall from the outside (but ONLY form the outside). BTW you should try to convince those groups that waterfall only looks good on paper and modern processes can yield better results, but it takes time, and probably you need to start right now with the project. How do you map RUP and Waterfall? Don't do the classic mistake of Inception=Requirements, Elaboration=Design, Construction=Coding & Unite testing, etc... you will be in trouble when at the end of Inception, the outside groups will ask for the complete requirements for review!

The trick here is map the end of Elaboration to the end Requirements phase, so you can collect all the requirements but also implement the critical ones. You can map the end of the Design phase to somewhere in the middle of Construction (or at the end if you can get away with it). When you're done with Construction, you can release your code to the outside QA team to do whatever they want. Probably is a good idea to have customer involvement early so he can try the system and provide valuable feedback (that's the whole idea!).

You will end with an oddly shaped (in time/effort) “Waterfall-looking” schedule but still all the advantages of an architecture centric iterative incremental methodology like RUP. And if you can't live without doing XP and will complain if you can't do it, you can safely do XP inside each RUP iteration...

BTW, by no means TRANSITION=TESTING!!!!