Sixty-One Requests, Thirty Million Dollars: Fixing the Lakeshore Prioritization Model
Lakeshore University's IT governance committee has $30M of capital for the coming year against 61 requests totaling $95M. Requests are scored with a weighted model (strategic alignment 40%, risk reduction 30%, ROI 20%, user demand 10%), and every input is self-assessed by the requester. Operating run-rate costs are not scored.
The top-ranked request is a $6.2M student success analytics platform whose business case claims $9M in retained tuition from improved retention, a figure the institutional research office has not validated. Ranked 12th is a $4.1M remediation of the student records system, which the external auditor flagged as a material weakness for the second consecutive year. Ranked 30th is a $700,000 identity and access management upgrade that IT says is a prerequisite for secure delivery of both the analytics platform and the records remediation. The provost has told the committee that the analytics platform is her priority for the year.
1. What is structurally wrong with the prioritization model, and how would you fix decision quality without simply overriding the ranking?
Read the worked answer
Four structural defects. First, self-assessment on all four criteria rewards optimism and penalizes honesty; strategic alignment and risk reduction are exactly the criteria a sponsor should not grade for their own proposal. Second, scoring ignores dependencies, so a prerequisite ranks below the projects that need it and its cost stays invisible. Third, capital is scored but run-rate is not, so the portfolio funds systems the university cannot afford to operate, and the real constraint binds in year two. Fourth, the model compares a project's benefit against zero rather than against the next best use of the same dollar, and it produces no partial-funding option: every request is all-or-nothing.
Fixes that preserve the committee's authority: have neutral parties verify inputs (institutional research or finance validates benefit figures; the CISO and internal audit validate risk claims); publish the scoring rubric with evidence requirements before submission; add five-year total cost of ownership including staff; build a dependency graph and rule that an enabler is funded with its dependents or its cost is charged to them; and replace full funding with stage-gated tranches, releasing design funding first and construction funding on gate criteria.
These changes are procedural. They improve the ranking's information content instead of substituting the committee's judgment for it, which is what makes them sustainable across cycles.
2. How should the committee handle the identity prerequisite, the audit finding, and the provost's stated priority together?
Read the worked answer
Treat the identity upgrade and the audit remediation as first-dollar items outside the discretionary ranking, and say so explicitly. A $700,000 enabler sitting at rank 30 is a modeling artifact, not a decision: if it is genuinely required for secure delivery, funding either dependent project without it means carrying the cost somewhere, usually as a change order later. The clean rule is that enablers are funded off the top, or their cost is added to every dependent request, which will reorder the list honestly.
The material weakness is a different problem with a different owner. A repeated finding affecting financial reporting controls may carry audit committee and bond covenant implications; the IT governance committee is not the right body to accept that risk. Escalate to the audit committee and CFO and ask for a written position on timing, then reflect it in the plan. Governance fails when a committee quietly absorbs a risk that belongs to the board.
The provost's priority is legitimate and should be expressed as a portfolio trade, not a scoring override. Present the consequence directly: funding the analytics platform at $6.2M displaces approximately X, and defers records remediation by one cycle and identity by two. Ask her to accept that trade in writing, or to nominate what she would cut instead. Recording the acceptance protects the committee later and keeps the priority honest, because sponsors rarely accept the trade once it is named.
3. What would you require of the analytics business case before releasing funds, and how much would you release?
Read the worked answer
Require evidence on the benefit first. The $9M retained-tuition claim needs a validated baseline retention rate, a defined comparison group, and a stated mechanism by which the platform changes retention; otherwise the number is a hope with a spreadsheet. Ask for the break-even point in plain terms: what retention lift, in percentage points, makes the investment pay back, and whether that lift has been achieved anywhere comparable. Institutional research, not the sponsor, signs off on the figure.
Then the cost side: five-year total cost of ownership including analytics staff (these programs typically need several FTEs the business case omits), integration with the student information system, data governance and FERPA obligations, vendor data-use and model-training rights, and the identity dependency. Confirm the identity upgrade is funded and sequenced before go-live.
Release funds in tranches: a discovery and pilot tranche in the range of 15-20% of the request, tied to gate criteria such as validated data access, a working prototype on real data, and a measurement plan with leading indicators. Hold construction funding for the gate, and specify a scale-or-stop decision at 12 months based on retention outcomes rather than on delivery milestones.
This is not obstruction. A sponsor confident in the benefit should welcome a structure that proves it early, and a sponsor who resists a pilot is telling the committee something important about the business case.