So, it sounds like you want something relatively fluid. If yesterday was a snow day you could add it the day after and then rerun calculations to look at the workloads (theoretically) required to meet deadlines.
Just thinking on the fly here:
Job ID, Name, Start Date, End Date
Dept ID, Name, WeekType
Job ID, Dept ID, Allotted Hours
Now, if you need to mess around with recalculations due to additional hours, deadlines extended, deadlines missed or other real life issues that intrude on simple solutions, you'll need a way to "recast" the project from a point in time.
You also have the flexibility, over time, to add additional departments. Maybe if a schedule can't be met third party developers would be scheduled and perhaps have different work days or hours per day expectations.
More pseudo-table thoughts:
Job ID, Dept ID, Recast Date, Hours Consumed, Hours Added, New End Date
In essence, for scheduling purposes nobody cares about the past after the recast (as you aren't trying to track hours worked or anything like that). The recast is conceptually a "new" project as of the recast date.
Now we get to the list of exceptions to the "expected" hours per day. I say expected as there could easily be days where hours are higher than the capacity to work for any number of reasons - including the ones you mention.
And more faux DB material:
Job ID, Dept ID, Date, Hours Excepted, Reason
Sewing some of this together it would seem that you could do date math on the number of project days (adjusting for weekends whether by list, estimating weekends within the period, or just looping through days and looking for non-work days as the project won't be all that long) minus the number of hours of exceptions found between the start and end dates.
However, if you allow for a recast, you should first see if you have adjustments to the project that need to be taken into account.
I expect this model would be fairly fluid for a system only expected to spread hours between dates going forward without attempting to account for actual time usage or employee level details.
Basically, just run all the non-ended jobs from the last recast, if any, summing exceptions* in the past to get work missed and summing exceptions* going forward to reduce expected work days between now to deadline date. Unless you have a zillion jobs it should be very fast - and every exception added after the fact turns prior calculations into lies anyway.
For bonus points, because this situation exists in the company I work for, you may have a different number of hours in the workday for departments in different geographies. If you wanted to show the number of people needed to meet the planned work effort you could put the hours per day in the department table to do the proper calculation.
I hope that gives you some things to think about. Of course, I won't make any promises for a series of quick thoughts but i'd be willing to prototype based on the above if I had to the same task (assuming I interpreted your question correctly).
Hope that gives you some ideas.
[*] Don't forget to estimate, generate on the fly or load previously populated weekend exceptions.