IT Prioritization GuidelinesPrioritization of IT projects is an institutional activity, not an IT activity. Support for the institutional mission and impact on the institution are the most important factors to be considered in priority setting discussions and decisions. Governance should ensure that IT projects are treated as institutional projects first, and that executive leaders prioritize based on the greatest benefits to the institution as a whole, looking for opportunities to remove current IT projects and services that cannot be justified as mission critical or institutional needs. Capture project value of ‘mission critical level’ and Impact (User, Dept, and Institution) to gauge value of IT requests. Even if funding is available, recommend to decline requests that satisfy few and do not provide value to institution.
Gartner Recommendations for Higher Education Project Management
Higher Education CIOs must work with executive leaders to set priorities and ensure that the value of IT projects are evaluated against their impact on the institution and their support of the institutional mission. Projects that directly support the mission and affect the whole institution are "high priority" projects. These are usually not difficult to sell and garner support from the rest of the community. Examples of such projects include replacement of a financial system that will go out of support from the vendor in 24 months and must be replaced. These projects may be costly and may require a lot of support; however, their impact is so crucial to management as well as the support of the institution that the value proposition is not difficult to sell. However, this does not mean that there isn't the typical political posturing that comes during the decision-making process on what the replacement will be. On the other hand, those projects that affect individuals only and are mission-neutral should be considered the lowest priority, and should not be done even when the individual or department has the money or political power to push through the project. An example of such a project is a request to change a budget report to look like an older version, even though the newer version has exactly the same information. While the time spent may not be great, there is no real value to the institution; technical support and skills are tight commodities that must be used wisely and effectively.
Projects that will require the greatest expenditure of time and energy engaged in priority setting are those that support departments only, but are moving toward mission-critical status. Priority-setting committees likely will spend their greatest amount of time discussing these projects. An example would be a departmental request from facilities for a key inventory addition to the employee data. While this is not mission-critical, and most academic and administrative departments will not have strong feelings about the need, it may well be important to facilities. In these kinds of requests, the requester will need to make a strong case to convince the priority-setting committee or process that the project request justifies the expenditure of scarce resources. Figure 3 can be effectively used by IT priority-setting groups to help make decisions about the priority and need for projects that are being requested.
- High Priority: These activities are "no brainers," and discussions are usually tied to project and financial planning as well as management more than discussions about whether they should be done.
- Shouldn't be done with limited IT resources: These activities are the most difficult to assess in priority setting. IT leaders should let departmental and political pressures play out before jumping in with "a solution." During tight budget times, these must be tightly scrutinized, and resources must be committed that do not draw from must-do projects.
- Below-value threshold: These projects shouldn't be undertaken no matter how much political pressure is applied.
We encourage institutions to establish policies that will prohibit "wealthy" departments from doing IT projects on their own and require them to go through an institutional priority-setting process. As more vendors market hosted models at the department level, there will be increased departmental interest in these seemingly independent options without considering the institutional IT priorities. CIOs must remind executive leaders that during tight financial times, not everything can be done and supported in the future. Those IT projects that show the greatest support of the institutional mission and the greatest gains for the institution should drive the priority-setting process. CIOs must ensure that IT projects are treated as institutional projects first, and that executive leaders prioritize based on the greatest benefits to the institution as a whole.
Specific to ERP Projects
Tightly controlled ERP customizations save time and money. Controlled customization provides opportunities for shared services. Formal customization reviews should ensure that customizations for which no business case can be made are avoided. Consider using customization reviews to ensure that departments benefiting from customization bear the cost when appropriate. Determine placement of customization cost by balancing breadth and depth of institutional impact. Institutions should consider the impact on total cost of ownership (TCO) as part of the overall decision-making process, including post implementation support. Cost-free customizations threaten overall project discipline. Departments should pay all or most of customization costs that are narrowly limited to their needs and institutional budgets should pay for broader initiatives. However, when failure to customize would bring about a serious mission failure, the customization could be paid by the central budget even when the impact is highly localized.
UT Arlington should focus its IT efforts on areas where university leadership determines the most value can be gained. Customizations are discouraged unless strong justifications are built and approved. Requests for change will first focus on suggestions to the vendor to provide the value rather than customizations. For those requests that are being considered, part of the supporting documentation should include determination of value based on cost to change/maintain versus cost to do without the change.