Start - Students are divided up into groups of 3-4, given a loose specification and told to implement solution in technology X by date Y (12 weeks away).
1 week in – No changes. Any requirements clarification requests by students are answered vaguely.
2 weeks in – Students are told they need to have a working prototype ready in 2 weeks.
4 weeks in – Prototypes are evaluated. Students are told to scrap prototype as second big functional change is introduced ("it has to be integrated into outlook", or "it cannot use any client-side script"). Teams are re-organized.
6 weeks in – Students are told the system must use data from a legacy system, which will be made available to them in coming weeks. A "representative sample" (laughs sadistically) will be provided to them (tell them in week 8). Representative sample is small, and structured in a very different way to the way the problem domain is currently understood.
10 weeks in – Legacy data is delivered. Some fundamental information is missing, and shows major discrepancy in way requirements are defined vs. data present to support requirements.
11 weeks in – Minor but annoying change to the environment the software has to run on. Possibly some left-field performance requirements thrown in.
12 weeks in – Project completion.
At any time students could negotiate to deliver less, deliver later, or "spend" more resources - although they would not be explicitly told they could do so. Push-back on requirements changes and schedule re-negotiation (based on said changes) would also be allowed, but also not explicitly stated. Although this sounds somewhat sadistic I think it would go some way to prepare students for "real-world" development.
If there's one thing you can count on about programming in the real world, it's that your customers will never truly understand their problem. If they truly understood their problem in all particulars, then they wouldn't be hiring someone else to solve it. Hence, they'll always be asking for changes - from hour 1 to hour 11. This is why the waterfall method of project management doesn't usually work in the real world. It's also why a signed piece of paper with all deliverables is so important in a flat-rate contract situation. Clueless management ("Week 4: Teams are re-organized.") is not as universal, but it is encountered often.