1. Introduction

Higher Education is a computer-based simulation game under development that targets both the institutional professional and the interested layperson to participate in leadership challenges in a college or university setting. Players set, monitor, and modify a variety of institutional parameters and policies, allocate resources as they see fit, and watch as results continually unfold. The game provides an opportunity to experiment and succeed or fail in a safe and entertaining fantasy environment. While Higher Education is necessarily a caricature of real academic life, it is grounded in authentic data and will provide serious lessons in higher education.

The game will be driven by a sophisticated simulation engine, described in Technical Documents 2.1 through 2.5, that models enrollment management, resource allocation and finance, academic operations, physical plant activities, and performance indicators. Several more algorithms deal with the game’s initialization procedures. The present Technical Document is the fifth in the 1998 (3.x) series:

Most of the material described herein has been prototyped in the Excel file "HE.Fac_Hiring.xls". The paper is intended to illuminate elements of the prototype, not to provide a free-standing explanation of the algorithms and procedures.

The faculty hiring model runs separately for each currently-active department that has been given an authorization to hire by the Stage 3 Resource Allocation Model. The salary-setting model covers all departments and runs only once. Salary data for peer institutions also needs to be updated annually.

The game’s faculty salary-setting and hiring models should run just before the beginning of each academic year (i.e., before the Fall trimester), after the resource allocation model. The hiring model should run after the salary-setting model. These two models can run either before or after the enrollment management model.

The objective of the faculty hiring model is to determine, for each new faculty member hired: (1) rank-experience and gender-ethnic characteristics; (2) in-hire salary; and (3) teaching, scholarship, and research talent. ("Rank-experience" is our new name for the rank-age categories described in Technical Document 3.3.)

Faculty hiring is prototyped on the "Hiring" spreadsheet. The sheet is divided into the five sections described below.

Enlight may wish to offer players the opportunity to override the Stage 3 Resource Allocation results and directly specify the number of faculty members to be hired by the department. This could be done by adding an appropriate constraint to the quadratic program, in context of the Stage 3 interface.

The model also would allow Player to hire or promise to hire an additional faculty member anytime during the year—e.g., in response to a complaint or while browsing a departmental screen. If effective immediately, such an action would initiate a hiring procedure and add to the current year’s expenditure. (The mid-year inhire salary budget would equal the average salary for an assistant professor. Other parameters would be the same as for the last hiring cycle.) The new faculty sim would enter the teaching roster at the beginning of the next semester. Research activities would begin immediately. Promises to hire (if not rescinded by later Player action) would add an override constraint the Stage 3 Resource Allocation program.

The hiring procedure depends on the following player-generated priorities:

1. The weights to be given to talent in deciding what kind of faculty member to hire. Separate priorities will be given for teaching talent, scholarship talent, and research talent.
2. The penalty weight to be associated with cost containment in deciding what kind of faculty member to hire. the Stage 3 Resource Allocation Model budgets new faculty members at the salary of the average assistant professor in the PGI. Actual salaries vary by rank-experience and gender-ethnic categories. The hiring model penalizes categories with salaries above this figure and rewards categories with salaries below it. The reward level is currently set at 20% of the penalty, though this may be changed.
3. The priority for hiring an assistant processor.
4. The priority for hiring a tenured faculty member: biases the result toward the tenured rank-experience categories in the following proportions: associate professor=0.5; full professor-1=1.0; full professor-2=0.75; full professor-3=0.4. (We may wish to change these figures during beta.)
5. The priority for hiring a long-term adjunct faculty member.
6. The priority for hiring a short-term adjunct faculty member.
7. Priorities for hiring minorities and women.

Player input will be by radio button: one button for each item. For buttons 1-4, the coding will be:

• very important: weight = 9
• important: weight = 4
• moderately important: weight = 1
• not important: weight = 0

For buttons 5-8 the coding will be:

• very important: weight = 4
• moderately important: weight = 1
• doesn’t matter: weight = 0
• don’t do it = -10

A zero weight implies indifference; the negative weight associated with "don’t do it" effectively prohibits the model from selecting the given type of person. All weights should be initialized to 1.

Enlight will decide where best to put these player inputs and what data should be provided to inform the player as he/she makes decisions. There may be a different set of inputs for each department. Data showing the breakdowns of continuing faculty numbers by rank-experience and gender-ethnic categories may be helpful, as might the figures for available talent (which depends on the salary stretch factor).

The main data elements are as follows:

(1)

The salary-talent elasticities help determine the talent available for inhires as a function of the ratio of the PGI salary to the average peer-institution salary for each rank-experience or gender-ethnic category. The elasticities may vary from department to department, but for new we will set them all to: teaching=0.7, scholarship=1.0; and research=1.2. These values imply that the market for teachers is inelastic and that for researchers is very elastic.

The calculation’s first step reconstitutes the salary data for the PGI and peer institutions. The salary for a given cell equals the numeraire salary (the average paid to white male full professors-2) plus or minus an adjustment equal to the numeraire salary times one minus the multiplier for the cell. For example, the adjustment for a minority female would be 0.027345*93825=2566. This formulation preserves the linearity needed for the last constraint in equation (3), below.

The next step determines the available talent by rank-experience or gender-ethnic category. The formula for rank-experience category i and talent index j is:

(2)

A similar formula applies to the gender-ethnic categories. In other words, the larger the PGI salary relative to the average peer-institution salary, the greater the talent PGI can command in the marketplace. This is where the question of above-scale salaries comes into play. Above-scale salaries increase the available talent.

The main calculation uses linear programming to determine what kind of faculty member will be hired. (The game engine will use its standard interior-point quadratic programming procedure with the quadratic terms set to zero.) The linear program formulation is:

(3)

where x and y are the variable sets for rank-experience and gender-ethnic categories and the weights (w) are determined by the player’s priorities as described in Section 2.1.

Equation (3) maximizes the weighted talent index, rewarded or penalized by budget savings or overruns, with respect x and y. Taken together, x and y determine what kind of faculty member will be hired. The linear program produces integer values (either 0 or 1) for each x and y under most circumstances. The value x_i=1 indicates that the hire is in the i^th category, and similarly for j. In the rare cases where the values are fractions between 0 and 1 (which occur when the budget constraint is satisfied exactly), we will round to the nearest integer.

The constraints on the sums over x and y ensure than only one person will be hired per iteration. The final constraint, which is expressed in standard "goal programming" form, defines the positive and negative budget deviations: D⁺=budget savings and D^–=budget overruns. The function cost[x,y] calculates the salary of the hire represented by x_i and x_j.

The linear program determines the characteristics of a single hire. The program is run iteratively if a given department can hire more than one person. All the inputs will be the same for the successive iterations except for the budget value. The new budget for each iteration is obtained as follows:

(4)

Budget_iter=1, which is the figure described in paragraph 5 of Section 2.2, is used for the first hire. Budget_iter=2 is used for the second hire, etc.. Equation (4) says that budget savings or budget overruns in one iteration count against the available budget for subsequent iterations.

Iterations after the first include one additional constraint that prevents duplication of the kind of faculty member hired. The new constraint requires the sum of the chosen x and y values for all prior iterations to equal zero, which drives them out of the solution. By avoiding duplication we add diversity to the faculty hiring program.

The resulting x-values determine not only the rank-experience and gender-ethnic characteristics of the newly-hired faculty member(s), but also his or her salary and talent indices. Salary equals the department’s numeraire salary plus adjustments for the chosen rank-experience and gender-ethnic categories. Talent is based on the aforementioned category and the inhire salary in relation to the equivalent for peer institutions. The newly-created faculty sim will use these values with no further adjustment.

The sim’s other characteristics (e.g., age, normal teaching hours, research activity) will be determined according to the procedures used in the game’s initialization, except that assistant processors will have no active research projects. Performance will equal talent and satisfaction will equal 80 at the inhire date.

The salary-setting procedure runs once each year, after Resource Allocation and before Faculty Hiring. This procedure applies to the PGI as a whole, not to individual departments. It supersedes Section 6 of Td_2.3, "Resource Allocation." The procedure is prototyped on the "Salaries" spreadsheet.

The following salary inputs should be included in the game interface.

1. Salary program by department: relative percentage increase for each active game department, expressed as a multiple of the overall faculty salary increase percentage produced by Stage 1 of the Resource Allocation program.
2. Salary program by rank-experience category: relative percentage increase for each category, again expressed as a multiple of the overall salary increase.
3. Relative importance of merit and gender-ethnic equity in distributing individual salary increases: radio buttons for teaching performance, scholarship performance, research performance, and gender-ethnic equity. The radio buttons will be labeled:

• very important: weight = 6
• important: weight = 3
• moderately important: weight = 1
• not important: weight = 0

1. Salary adjustment for individual faculty sims: the player can change the salary of any sim, at any time, by accessing that sim and making the change. Changes should be expressed in dollar terms. They can be positive or negative, but negative changes will elicit bitter complaints, loss of morale, and possibly lawsuits (a "chance" event). [Note: this feature may have been deleted.]

All parameter values should be initialized to one.

Like other mid-year changes, the salary adjustment can be made effective immediately or promised for the next salary-setting cycle. (A promise will always be kept unless Player explicitly amends it.) Once implemented, the change becomes part of the faculty member’s base for use in all subsequent calculations.

Enlight may wish to incorporate the interface for Paragraphs 1-3 as part of resource allocation. Providing the ability to access appropriate parameters, anytime during the year, from the departmental screens and/or in response to complaints by individual faculty would enhance playability.

The salary-setting model uses the following data from other parts of the simulation engine:

1. Overall faculty salary increase percentage (p): equals inflation plus the real salary increase percentage calculated by the Stage 1 Resource Allocation model.
2. Faculty numbers by department and gender-ethnic group: obtained by counting the faculty sims after determining departures but before hiring.
3. Average over departments of prior-year salary multipliers by gender-ethnic group: weighted geometric averages of the departmental multipliers calculated during the prior year’s hiring process (we’ll ignore the effect of this year’s departures).
4. Faculty salaries for individual faculty sims: including mid-year adjustments, if any, but not including promises.

Step 1 implements outstanding promises, if any, for individual adjustments. These sims should be flagged and excluded from all subsequent calculations. Furthermore, the amount of the adjustment should be subtracted from the total sum available for the rest of the salary program and the overall percentage increase (p) recalculated. (The initial total equals p times the prior year’s salary base.)

Step 2 translates Player’s priority for gender-ethnic equity into salary program multipliers for gender-ethnic groups. These multipliers equal the reciprocals of the corresponding multipliers for actual salaries, multiplied by a scaling factor (sf): sf = priority/6, so that the top priority produces "1" and the lowest "0".

Step 3 calculates a raw salary adjustment for each faculty sim. The raw adjustment is obtained as follows:

1. Base increase = current salary * the overall percent increase (p).
2. Department adjustment = current salary * (department multiplier–1).
3. Rank-experience adjustment = current salary * (rank-experience multiplier–1).
4. Gender-ethnic adjustment = current salary * (gender-ethnic multiplier–1).
5. Preliminary merit adjustments = base increase * merit priority * (performance/100), separately for teaching, research and scholarship.
6. Overall merit adjustment = weighted average of the preliminary merit adjustments, where the weights equal the individual priority divided by the sum of the priorities.
7. Raw overall dollar increase = max[0, sum of elements 1, 2, 3, 4, and 6 above]. The "max" function ensures that no adjustment will be negative.

The final step multiplies the raw salary increases by a scaling factor so their total conforms to the adjusted institutional percentage increase (p). The scaling factor equals the institution’s total salary increase budget divided by the total of the raw salary increases. Everyone gets the overall salary increase percentage if there are no departmental, rank-experience, gender-ethnic, or merit adjustments. Otherwise each sim gets a blend of the various adjustments. The individual adjustments may cancel themselves out in some cases.

Player can create a new department at any time by accessing an interface screen being designed by Enlight. The department must be from the set included in the game’s database. The department-creation procedures have not been prototyped.

The act of specifying a new department:

1. Creates a new building on the campus map, with associated interface screens. The new building will appear immediately.
2. Hires a white male full professor-2, effective immediately, as the new department’s first faculty member. (Hiring the numeraire faculty member first allows a major programming simplification. While this may appear troublesome to some players, they can dictate other gender-ethnic groups for all future hires.) Additional faculty can be hired immediately if the mid-year hiring feature has been implemented, or during the next hiring cycle.
3. Adds cost to the staff salary and "other" columns under "academic departments" in the Sources and Uses of Funds table. For now, let’s say $100,000 for staff salaries and $50,000 of other expenses. These costs and the costs of the initial faculty members will be added to the PGI’s current-year expenditures in the usual way.
4. Initiates student course-taking and major selection at the beginning of the next semester, using the usual procedures, based on the department’s then-current faculty numbers and characteristics.
5. Creates a new departmental variable in the Stage 3 resource allocation interface.
6. Adds variables for the new department’s "space norm" and "space inventory" to the facilities interface. However, these variables will not be active until the facilities model is run at the beginning of the following year. At that time the space norm will be calculated by the usual formula based on faculty numbers, prior-year student enrollments, etc.. The space inventory will be zero, which will place an immediate call on the capital budget. Modeling convenience suggests that no facilities-related faculty or student morale penalty be assessed during the hiatus between department creation and the next run of the facilities model. However, the usual penalty formulas will apply from then on.

Because there is no PGI faculty history for the new department, hiring will depend on the peer-institution parameters. The normal salary scale for inhires will equal the normal scale for the peers, although players may pay above scale to buy extra talent if they wish. Adding faculty to the rank-experience and gender-ethnic categories will gradually build up PGI experience and reduce reliance on the peer institution in the determination of the new department’s salary scales.