How do you structure broad, open-ended, freely chosen projects so that students use class time wisely?
The first step is for the students to design their own projects.  I give them a timeframe, and make clear that they will be held accountable (within reason) for finishing the project.  I don't just accept the project proposals blindly - there is a negotiation here.  

There's an odd twist to this step, actually: I often have to persuade the students to lower their sights a little bit, because they often have a poor sense of how long their grand idea will actually take. 

Any changes after my approval, however, must run through me.

Every other Monday, the students and I negotiate/create biweekly mini-milestones.  They know how many weeks they have to complete the entire project, and they then tell me what they feel they can get done within a week.  It has to be highly specific (so that it can be evaluated), and both the students and I must feel that it would mark sufficient progress towards their overall project goal.  (In my experience, I find that I simply accept their goals directly about 75% of the time, and in the remaining 25%, I have to steer students towards easier goals about as often as harder ones.)

When the actual evaluation takes place, if they have met the goal, then they only need to tell me what they intend to accomplish for the next week.  If they have not met their goal, then we have a more in-depth conversation to figure out how to recover so that the project still reaches completion.

That's the mechanics of it.  A few interesting takeaways:


One of the greatest joys of the entire enterprise is just getting a chance to ask them questions during the weekly check-ins.  I've personally never created a Chrome extention, a Unity game, a Flash game, or an iOS app, so getting to ask questions about the model code they've found, and the changes that they are making, teaches me quite a lot.
Using this structure, I don't have to weight the final project itself as heavily as you might think.  If the mini-milestones are well-formed, then the projects almost always come out very well.  In the few instances where it does not, the mini-milestone structure has ensured good work throughout, and there is typically some external factor that got in the way.  The grading seems to be more fair this way.