Hope you got a nice bonus for pulling this off so fast (but working for the state, I doubt it).

There is another way of structuring the fact table which would be much more flexible in the event questions were added to the survey, or the possible answers became more than just 3, or what the possible answers were varied by question: introduce two new dimensions, a Question dimension with one member per question, and an Answers dimension with one member per possible answer (across all questions). Create foreign key relationships between these and the fact table. Then, instead of one measure column in the fact table per question/answer combination, just have a single numeric measure column whose value is always 1 for each row. This is possible because each row in the fact table represents a particular survey #/Question/Answer combination. Non-existent combinations don't exist in the fact table (or if they did, then the value should be zero and they wouldn't hurt anything). Then you can just aggregate this measure (no counting needed) and still get all slices desired. To replicate the query result shown in the article with question/answer and count would now require placing both Question and Answer dimensions on the rows.

Of course, the UI for entering the results and the underlying relational schema would need corresponding adjustments also were any of these changes in question/answer possibilities to occur.