|The stupid question is the question not asked|
When you learn something, you are most effective if you are able to "latch on" to something you already know and build from there. So, your task as a teacher is to figure out what they already know, compare that to where you want to get them, then build the bridge.
Part of the problem is that they already have prejudices about programming - that it's hard, arcane, and confusing. Of course, we all know that programming is nice and easy, but you have to convince them in their innermost heart of hearts that this is true. And, the neat thing is that it's really easy to go about it.
Everyone knows how to give directions from point A to point B. Well, that's all programming is - giving directions to a moron that will remember everything you tell them and do it as often as you want. So, start them out with exercises on giving directions. Get them to give even more and more detail, because you have to assume the person has less knowledge of the world. I'd progress something like this:
As they get more and more complex, go from a list to a flowchart. Then, show them how the flowchart of their directions (with all the added stuff) gets converted into pseudo-code. Presto! They've just written their first computer program. This should take about 2 hours.
At this point, it would be good to break for 10 minutes, let it soak in, then split into small groups in order for them to do another, similar problem. Leave the first one on the whiteboard for reference. After an hour, let them present their solutions.
After lunch, now that they have connected the act of programming to something they already understand, they will have the necessary scaffolding to hook all the stuff you want to teach them. Your syllabus is just fine.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
I shouldn't have to say this, but any code, unless otherwise stated, is untested