I think a script is actually more harmful than good. It tends to produce very rigid talks, and it often forces you to concentrate on the _script_ instead of the _content_ and _audience_. Usually, you know what you are talking about well enough to not need a script, and just pointers. Below are the tricks I use for different kinds of talks. ###Research talks For technical talks on my research or guest lectures on topics I am intimately familiar with (these two have been the overwhelming majority of my talks), I do not make scripts or notes and just concentrate on making good slides. In the process of making slides, I produce an outline which I use to mentally check my timing. The day of the talk, I look through my slides carefully (hunting for typos and other minor mistakes), this reminds me of the exact details I was going to discuss. Since I tend to repeat similar talks, I have become very proficient at estimating my timing. For some big conferences, I practice talks in my lab before heading to the conference. This greatly improves the talk, especially timing issues and comfort. I find that this is easy to do because you are usually intimately familiar with your own research and unlikely to forget something. It also allows a relatively fluid and natural talk, and lets you answer questions during the talk without fear of losing your pace. Usually, __I have my final version the day before__ unless I rehearse in the lab. ###Teaching talks I have done a number of talks as reviews for large bodies of students (50 to 300) to prep them for exams, and smaller groups (20 to 30) during weekly tutorial sections. Here I was talking not about my research, but course material that I had taken years ago. The topics were physics/math and my style was one of interactive problem solving at the board of hand-picked problems that illustrated key concepts. To prepare I had to invest time to carefully come up with good questions and I quickly checked that I could solve the questions as I generated them. I write down the questions one per page with a few bullet points of the main concept/technique I want to show in the question. However, I do not write down solutions and solve the questions on the spot at the board. This puts a certain amount of stress on me (especially if you are teaching first year engineers) but I find it produces much better pacing for the students (since I naturally slow down a little at the harder parts) and actually solving the questions as you present them instead of copying a solution from your notes to the board keeps you in the zone and actually reduces errors. Not having notes in your hand (except to write down the problem statement) also lets you worry about just two things: the board and the students. The caveat is that you have to very comfortable with the material (but why are you teaching it if you are not?!) and you need to have the confidence to laugh at yourself and recover from occasional mistakes. Usually, __I have the final questions and plan a few days ahead of time__. However, there is no 'final version' of the actual talk, since it depends completely on the audience. ###Popular talks My only opportunity to give a popular talk was at [TEDx McGill 2009](http://www.youtube.com/watch?v=bRuE3oP-JT8). This was incredibly different from other talks I am used to. Thankfully, all of the speakers were coached by the organizing committee ahead of time (including a full dry run through). The key message was to treat this not as a presentation, but as a performance. I did not prepare a script (and were were advised against preparing one), but I did make notes on cue-cards that I held during the performance. Except for the very beginning (where I was unusually nervous) I never looked at the cue cards, and mostly held them for comfort. __I had my final version about a week before the talk__ and my ready-for-dry-run version about two weeks before.