 |
| Ameera Shah |
Super investor Warren Buffett famously made two unexceptionable rules: Rule No.1: Never lose money. Rule No.2: Never forget rule No.1. These rules do not go the regular way when applied to healthcare IT investments. It is rather difficult to know whether you lost money or gained it. This can particularly get daunting for IT sorcerers, trying to justify costs for something as intangible as technology. “Ask 10 of your colleagues what e-business which issue burns hottest today, and nine of them will tell you ROI” (David Joachim, Senior Managing Editor, Internet Week). Does this imply that IT can chide ROI? Essentially not. Remember the two rules?
So, how can one tackle this incomprehensible trouble in the budget-bull-fight business environment? The answer must lie in the approach that we tend to adopt while proving ROI. Before that one needs to understand that in healthcare, benefits are usually found in cost avoidance rather than revenue enhancement1. In the traditional ROI analysis one weighs the operational costs against the revenue gains from service delivery. Traditional analysis is suitable to evaluate tangible investments like money spent on marketing, promotion and weighing them against the increase in sales. For technology, one needs to be unconventional and bring home a more diverse setting for ROI estimation. This setting would begin by defining the objectives of the investment in the overall organisational and extra-organisational context. Finally proceeding to, positioning the investment in the overall organisational goal. Simply said, if bucks earned in numbers cannot be counted, depend on the objectives which could be measured.
Presenting healthcare IT investment
The project approach: Technology investments come with a high risk of failure. If technological development is viewed as a continuous self-development exercise, then mind yourself bumping into an inextricable question: what are we really doing? A continuous technological development approach may not have deadlines, no specific objectives and even worse; no vision. This might induce an inherent risk of non-productive investment. So tipping the faith of investment into your favour would be increasingly more difficult. Furthermore, the fear of losing track would haunt the investment decision. Adopting a project approach would work best in your favour, since with this approach it would be possible to adopt measurable objectives for the technological development, or shall we say investment. A project is time bound, which would help instil faith in the investment and development. Since IT development tends to be more continuous rather than a onetime development deliverable, you probably already have a compelling doubt in your mind…how can one wrap this continuous development trail into a small box of project? Well then, at the outset begin the development as a project that wins the first justification for investment. Later depending on the complexity and nature of development required, evolve the project into a regular IT departmental/ sectional activity or into a continued development programme. The complexity of further development; in monetary terms would simply mean, how much more money would be needed? If the projected financial needs are high, the development process still remains complex. The road ahead of project completion would depend on how well the project met its specified objectives.
Setting objectives in lieu of calculating ROI
In the battery of objectives for the project, do not forget to include numerically measurable objectives. Let me cite an example; say you are intending to develop a management information system for your managers to draw reliable and sensible information from. You could perhaps include a measurable objective of percentage reduction in time spent on regular decision making activities, and therefore the spared man hours. You could go a step ahead and equate the man hours saved with the money saved. However, numerical values would call for some data collection, which could compare situations quantitatively before and after project implementation. Since fulfilling the measures for numerical objectives would call for additional expenses and time, it would be a good idea to include qualitative or descriptive objectives, measured largely based on perspectives.
Aligning objectives to overarching organisational goal
Aligning objectives to overarching business objective would be an exercise of reassessment. Once the project objectives have been set, it would be a good practice to see them through the lens of overall organisational goals. An example would be, say your project objective is to reduce the customer query response time by 30 per cent. On seeing through the organisational goal lens, this would possibly mean enhanced customer satisfaction. This in turn would lead you to consider more parameters which could be included in the ROI calculation. A possible inclusion parameter would be; more frequent interaction with customers through reminder health check-up emails and increasing their adherence to your services.
Accounting for risk factors
IT projects would come with inherent risks, broadly classified into technological risks and organisational risks. Technological risks can be controlled to a large extent by the choice of technology. A well proven and matured technology would have a minimised technological risk, whose choice would be limited by budget constraints. The choice of technology would thus be a trade-off between the expenditure and the risks in the technology. Once the choice is made, you are posed with the organisational risk, which is seated in the implementation of technology. There are numerous examples of excellent technologies been overthrown on account of organisational rejection. The costs incurred due to organisational risks are potentially very large, which magnifies with further stages in implementation. These risks confound with the ROI and hence should be meticulously accounted for.
Setting boundaries
The approach of measuring ROI would itself turn out into an unending painful exercise, if not contained into boundaries. Drawing the borders for ROI estimation should be closely tied up with the measurable objectives. How deep should the ROI estimation penetrate and before that whether or not the estimation in question should be conducted at all, is an important question. Drawing boundaries would be a collective decision more than an individual decision. In most cases the cost incurred in the ROI estimation itself would be a eciding factor. Budget constraint of the project would be the most persuasive factor for ROI calculation measure decisions. Hence, in order to set the boundaries, you might want to look into the measures which would not incur any additional expenses. Collecting data for ROI while project implementation itself, say for example the average time taken to maintain paper records, would be a good example of inexpensive measure for ROI certainly better than planning an elaborate study post project implementation.
In conclusion
Conceiving IT development through a project approach is the key to measuring ROI for technology development. While doing this, an executioner should conceive the project traversing beyond technology into a larger organisational context. This wider approach would not only help finding suitable objectives and measuring parameters for ROI, but would also allow the project to become more tangible and effective. Bottom-line is that a well-conceived and well calculated ROI would make the technology development project gather more muscle for the budget-bull-fight, a fight which is largely governed by rule 1 and 2, as spelt out by our Buffet.
References:
HIMSS. EHR and the Return on investment, http://www.himss.org/content/files/ehr-roi.pdf, accession date 12th May 2012
- Advertisement -
