John Glaser

There will always be more demand for IT projects than an organization can afford or manage.

As a result, organizations need to make decisions between competing proposals for IT resources: "Which projects will we fund, and why? And what steps can our organization take to ensure that the prioritization of IT projects is as thoughtful and effective as it can be?"

The answer lies in carefully prioritizing the IT projects that your organization undertakes to ensure that they provide the maximum value. Effective IT project prioritization has four components:

  • Sound project proposals 
  • An IT strategy that can guide decisions  
  • Solid processes for evaluating and comparing these proposals 
  • Steps that can be taken to "re-scope" the project

The Project Proposal

The IT project proposal is a cornerstone of the prioritization process. These proposals request money and the organizational commitment to devote management attention and staff effort to implementing an information system. The proposal describes why this investment of time, effort, and money is worth it.

To be effective, IT project proposals should address several key points.

Business sponsorship. All projects should have the goal of improving the performance of some (and at times all) sets of the departments and functions of the organizations. The sponsors are the leaders of the beneficiary departments. They are the ones who will need to lead the effort and be held accountable for results.

Purpose/objectives. The project goals and objectives need to be clearly stated. What is the purpose of the project, and how will it benefit the organization?

The IT solution. The requested application and/or infrastructure must be described, with an emphasis on the importance of application functionality.

Timing. The amount of time required to perform the project, as well as any considerations that would determine when the project could be initiated, should be stated in the proposal.

Cost. The expected costs of the project, including the necessary commitments of existing staff, need to be included in the proposal.

Benefits/value. The specific performance gains that should be achieved by the project must be defined. These gains should be measurable, although not all gains will have a dollar value.

Related changes/initiatives. IT projects often will involve changes in existing processes and may have interdependencies with other initiatives, such as the opening of a new building.

Risks. Possible risks to the project (e.g., the need to utilize cutting-edge technology or the requirement of significant organizational change) should be detailed in the proposal.

These proposals need not be elaborate or lengthy; three to five pages are often sufficient. They must, however, be clear, well researched, factual, and devoid of hyperbole.

Assessing an IT Proposal

It can be difficult to assess an IT project proposal. The proposal reviewer may not have deep knowledge of the department or the proposed application. Most project proposals forcefully sell their case. How will the reviewer know whether the opportunity is truly significant, or whether the estimated costs represent the full cost of the project? 

There are no easy answers to these challenges. There are several points that must be considered as an IT proposal undergoes review.

The track record of the project proponents. Clearly, business sponsors who have a history of "delivering the goods" are likely to continue to deliver the goods.

The uniqueness of the project. There is a lot of industry experience in implementing systems such as clinical laboratory and ambulatory scheduling. Hence, there is a lot that is understood about the costs and benefits of these systems. Proposals for these kinds of systems should show that the experiences of others have been factored into the analysis.

The quality of the proposal. Proposals that are well written, include substantive data, and are clearly presented usually demonstrate a quality of thinking that will permeate the proposed project. This does not mean that slick proposals are equivalent to successful projects, but thoughtful proposals usually indicate competent proponents.

Mechanisms for Evaluating and Comparing IT Proposals

It is very challenging to compare IT proposals that have different value propositions, time frames, and orientations (e.g., the difference between a network upgrade and a new pharmacy system). How does one compare a proposal that promises to increase revenue and improve collaboration with a proposal that offers improved compliance, faster turnaround times, and reduced supply costs?

At the end of the day, judgment is used to choose one proposal over another. Managers review the various proposals and their value statements and make choices based on their sense of organizational priorities, available monies, and the likelihood that the desired outcomes will be seen.

These judgments can be aided by the development of a scoring approach that helps to develop a common "metric" across proposals. For example, the organization can decide to score each proposal according to how much value it promises to deliver in the following areas:

  • Revenue impact 
  • Cost reduction 
  • Patient/customer satisfaction 
  • Quality of work life 
  • Quality of care 
  • Regulatory compliance 

Each proposal is assigned a score for each area, ranging from 5 (significant contribution to the area) to 1 (minimal or no contribution). The scores are totaled and, in theory, the proposals with the highest aggregate scores are the ones that are chosen. In practice, IT investment decisions are rarely that algorithmic. However, such scoring can be very helpful in sorting through complex and diverse value propositions.

Scoring forces the leadership team to discuss why different members of the team used different scores to evaluate the project. For example, why did one member of the leadership team assign a score of 2 for the project's potential impact on revenue while another member of the team assigned a score of 4 in the same area? Resolving differences in perception will help to clarify any misunderstandings of proposal objectives and enable the team to arrive at a consensus regarding the project.

Scoring also means that the leadership team will have to defend a decision not to fund a project with a high score or to fund a project with a low score. For example, why would an organization be in favor of an IT project if it did not score highly?

The organization can decide which scoring criteria to use and which to discard. Some organizations give differing weights to specific criteria. For example, the project's potential to reduce costs could be weighted twice as heavily as its potential to enhance patient satisfaction. The resulting scores are not binding, but they can be helpful in arriving at an organizational decision regarding which projects will be approved and what value is being sought from the projects.

The group doing the prioritization should be composed of a well-balanced spectrum of the organization's senior leadership. This balance will enable all viewpoints to be heard, while the senior level of the participants will add a broad strategic and operational perspective to the decision-making process.

Ideally, the IT prioritization process should be well integrated into the overall processes for defining capital budgets and organizational priorities. At times, IT projects are less important than initiatives such as constructing a new ambulatory care center or expanding a service line. Moreover, there is a limit to the number of projects, IT and non-IT, that an organization can handle at any time. Ensuring that IT priorities are assessed in conjunction with other priorities helps to ensure that there is an appropriate balance of investments of capital and organizational energy.

The IT Strategy

IT strategy has been discussed over the course of several Digital Perspectives columns in hfm. This discussion has included the challenges of developing an IT strategy and the different perspectives that can be used in developing an IT strategy.

At the end of the day, an organization's IT strategy will describe a series of important applications and technical infrastructure (e.g., wireless capabilities) that will be needed if the organization is to achieve its strategic goals and operational plans.

For example, if the IT strategy calls for the implementation of an electronic health record, then the resulting project proposal is likely to be approved. Approval does not inherently mean that key aspects of the project, such as the project budget, pacing, and when to begin the initiative, will not be discussed, but it does mean that the project will not be turned down.

The presence of an IT strategy clearly helps the prioritization process. However, the IT strategy does not reduce the prioritization challenge to a trivial undertaking. The budget may not enable all of the applications listed in the strategy to be funded in any given year. And invariably, many worthwhile applications will be proposed that will ultimately not be included in the strategy. For example, small departmental systems that are not significant enough to be deemed strategic, yet are nonetheless valuable to the organization, may not be included in the strategy. Moreover, the needs of the organization may evolve to the point that portions of the IT strategy become out of date.

Rescoping an IT Project

An organization should not believe that it has to accept the scope, budget, and timing of the project as stated in the proposal. Unlike the Ten Command-ments, proposed projects can be changed or rescoped. These changes can help to spread limited resources over as many projects as possible.

Rescoping of an IT project generally happens during the prioritization processes. Several considerations may be considered.

Some requests are "mandatory." A status of mandatory can result from a regulation requirement, or it may be imposed when a current system is so obsolete that it is in danger of crashing- permanently-and must be replaced soon. Mandatory requests must be funded.

Some projects can be delayed. These projects are worthwhile, but can be delayed without detriment to the organization. 

Groups within IT-e.g., the staff who manage clinical information systems-may already have so much on their plate that they cannot possibly take on another project. Although the organization wants to initiate the project, it would be ill-advised to do so now, and so it would be best to defer the project until a later date.

The department proposing the application may not have strong management or may be experiencing some upheaval. Hence, implementing a new system at this time would be risky. The project could be denied or delayed until management issues have been resolved.

The value proposition and/or the resource estimates are shaky. The leadership team does not trust the proposal, and it could be denied or sent back for further analysis. Further analysis could mean that the proposal will be revisited the following year.

There are believed to be less-expensive ways to address the problems cited in the proposal. Alternatives may involve a less-expensive application or a non-IT approach. The proposal could be sent back for further analysis.

The proposal is valuable, but its budget can be reduced. In this event, progress will occur, but at a slower pace. This will delay the value of the IT project, yet ensure that resources are devoted to making progress.

Finding the Right Balance for Your Organization

Healthcare organizations will always face a challenge of prioritizing the demand for IT projects. This process will never be easy and will fundamentally be based on judgment and consensus. Nonetheless, the process can be more efficient and effective if the organization has sound project proposals, solid processes for evaluating and comparing these proposals, a clear IT strategy, and an understanding of steps that can be taken to re-scope the project so that it provides maximum value to the organization.

John Glaser, PhD, FHIMSS, is vice president and CIO, Partners HealthCare, Boston (

Some of the content in this column has been adapted with permission from Managing Health Care Information Systems: A Practical Approach for Health Care Executives, by Karen A. Wager, Frances Wickham Lee, and John P. Glaser, Jossey-Bass, May 2005.

Publication Date: Saturday, July 01, 2006

Login Required

If you are an existing member, please log in below. Username and password are required.



Forgot User Name?
Forgot Password?

If you are not an HFMA member and would like to access portions of our content for 30 days, please fill out the following.

First Name:

Last Name:


   Become an HFMA member instead