Here are some general observations:
1) Manual scheduling is rarely attempted from scratch. Instead, somebody starts with the schedule for the previous year and alters it to take account of changes in requirements. One way of mimicing this with a computer is to use a hill-climbing algorithm, which repeatedly tries a number of small changes to improve a solution so far. This can then be started off at the current schedule.
2) Does the manual process ever terminate with the conclusion that the requirements are collectively unachievable and that some of them must be dropped? In that case your algorithm must be transparent enough that failures can be understood, or at least capable of proposing such changes (e.g. by maximising a penalty function which allows it to produce a "least bad" solution which does not satisfy all of the original constraints). I know of one case where a sophisticated constraint-based approach was replaced by a much simpler algorithm because failures of the constraint-based system did not give enough user feed back.
3) Curiously enough, the next generation system did not use sophisticated scheduling at all. It turned out - roughly speaking - that at the time the decisions had to be made not all of the consequences of sophisticated scheduling decisions could be forseen, and, in the long run, a simple predictable schedule that could be maintained indefinitely was more productive than constantly rearranging schedules to grab small momentary advantages.