How to Justify an IT Project With Uncertain Returns (And Still Make Your CFO Happy)
A cash-strapped IT manager makes the case for a business intelligence system one data analysis at a time.
Start Small
To make the project more palatable financially, we broke up a large BI implementation plan into multiple cascading sub-projects, each of which built on the success of its predecessor. The value delivered by each step would be used to fund each subsequent step. Planned and executed correctly, the end result would be a low-risk, high-reward project delivering positive value from the first success. Because the project could not continue if any step did not deliver value, the CFO was convinced.
The reason we got the green light is that, as Internet pioneer David Reed concluded (in what has become known as Reed's Law), the value of the network comes not from its capacity, but from the transactions conducted on it. If there is no feasible action the organization can take, then the information the system would uncover has no value and you shouldn't build it. Reed's law of network value was pivotal in our requirements analysis. We identified first the areas where we knew we could deliver a positive value at a low cost—using existing tools wherever possible. For us, that meant building on existing Microsoft SQL and IBM Universe platforms, and building client side views using Access, Excel and basic Web services. As the BI initiative grew, we added the free version of Microsoft Office Sharepoint Server (MOSS), and plan on adding MOSS Enterprise features using some of the savings already delivered.
In one of the first steps, we focused first on patient wait times. Due to the often urgent nature of our practice, the office can fill with last-minute patients and we occasionally have excessive wait times. Historically, the practice felt this was unavoidable. Executive leadership set as a priority for this year to develop a report card about the problem and suggest corrective action.
Working with the clinical manager of the affected area, we started with simple data discovery from our patient charting system. As a patient moves through the practice, his or her location is entered into this system by the clinical staff in order to ensure that patients get the proper tests before and after their visit with a physician. The time stamps and locations of these events had been logged for compliance purposes, but we had no report to analyze this data.
So we used our BI tools to dive into the data to see what was there. For each and every patient, we had a start and end time for each step of the process, which could then be computed into a statistical model of the typical patient visit. We learned how long typical patients sit in the waiting room and in the exam room waiting for the physician, how long they wait for an assistant, and how long they wait for certain tests. When we compared this data between physicians, visit types and locations, we learned (among many other discoveries) that the scheduling template we use is a key component of patient wait times, and that our model did not leave enough room for handling the additional traffic from urgent care visits that occurred during the day.



