The reason fire drills are useful is because they introduce familiarity and rote to a traumatic event. Trauma (dramatic and sudden changes in a stressful situation) breeds panic which affects judgement and leads to poor decisions causing accidents unrelated to the actual trauma: people fall down stairs, get crushed, lost, suffer from heart attacks and asthma attacks, get into fights, etc.
By introducing an element of familiarity (what the alarm sounds like, where the emergency exits are, what to take, where to go, how long it takes to get there) the drills eliminate the need for decision-making and even if they panic the training will kick in and people won't have to make fateful decisions.
It's also the reason surgeons, airline pilots and astronauts (to name a few) use strict protocols for resolving critical problems: no matter how much they train and practice, it's safer if the decision-making is taken away during those moments of high adrenaline. Follow the steps and you'll be ok. Think and you'll make a mistake.
This idea can be taken into games. Although less traumatic and certainly less dangerous, there are phases of a project where a mistake can have dramatic consequences: missed deadlines can affect milestone payment, project investment, signing of contracts or revenues.
The solution is to identify these high-risk points and to create repeatable steps that can be practiced and rehearsed by the team so that on the day you can just push a button to trigger the process and everyone knows what they need to do.
For example, milestone deliveries are always a traumatic event. If you create a step-by-step plan to prepare the submission that you repeat for every milestone, you will make things a lot easier for the team: the little things will take care of themselves and the team will have more bandwidth (time, money, energy, morale, creativity) to solve the real problems, the unpredictable problems that inevitable will happen in a creative environment.
So for a milestone delivery due on the Friday the week could look like this:
Monday: code lock;
Tuesday-Wednesday: testing the milestone requirements (and fixing the bugs that will prevent the milestone from being approved)
Thursday: testing to confirm the bugs are fixed, building, delivering
Friday: contintency to build and deliver in case something happens on Thursday
Define the steps, present the steps, practice the steps. Everyone should know what they need to do for each step. There will be stumbling at first, but keep at it and eventually everyone will find their mark and understand how they need to contribute.
Better yet, you could deliver a milestone-quality build (including documentation, build notes, etc.) every two weeks. A full dress rehearsal that will create a heartbeat for the team. After a few times you will have created a momentum and the process will be a formality: the team will be able to run it without you - and you can focus on the bigger problems.