Transit information technology – build versus buy
By Mary Sue O’Melia
An agency’s Information Technology Department is tasked with finding a better way to report information. Did the agency decide to build or buy? Does the agency now get timely information, or is it still waiting?
You can get better, but you can’t pay more
It’s the summer of 2007 and I am at a transit agency board meeting. Sitting next to me in the audience waiting to speak is a project manager of an ambitious ITS project. He is presenting an overview of the recently completed “middleware” project and proceeded to explain that middleware was a data warehouse for farebox, customer service, AVL and onboard vehicle diagnostic equipment. I asked how much this project costs – $100 million he said. I asked what kind of reports they were getting – he said none; that is the second phase of the project. I asked about maintenance and return on investment – he said that other agencies in the region were going to participate by adding their data to the project. I asked what this would cost – he said $15,000 per vehicle and then $1,500 per vehicle annual maintenance. The ITS project manager gave an example to the policy board of how this data could be used to improve service – data from the new AVL system was being used to investigate and validate customer comments.
In the fall, I was once again sitting in the audience of the same policy board. The ITS project manager was there to give an update. It seems that the union had protested the use of AVL data to validate customer complaints. Two years later, the executive director of this same agency stopped by our booth at a trade show and picked up a sample report noting, “I would have to wait a million years to get a report with basic route-level performance information.”
The Dashboard craze – build or buy
In 2008, interactive Dashboards with drilldowns became the rage. Speedometer-type gauges become the standard in data visualization. Our company started looking for someone to build a set of Dashboards. We were about a month and $20,000 into a proof of concept project with a consultant specializing in dashboard development. It became very clear that at this pace, it would be years to develop a full suite of transit functional area dashboards.
In 2008, we got smart and searched out and procured a Business Intelligence solution. This was better than custom programming, but still required significant development time (two to four weeks once the design had been agreed upon). By 2012, it was clear that the world of Business Analytics had moved on – it was time to update.
Once again, we had the “build or buy” decision. Operations investigated the options and came to the conclusion that many IT Departments reach – it is more cost effective to build our own. Twelve months, and one Key Performance Indicator (KPI) Dashboard later, it was clear that we were not accomplishing what needed to be done – the goal was one functional area dashboard per month; not one per year. Operations decided they needed help and outsourced four of the 12 planned dashboards. After six months, one of four projects was completed, but the visualization was too ugly to put into production.
Anything is possible with enough time and money
The build-your-own approach is really NOT less expensive. The costs are just better hidden and often times not understood at the project start. For the past month, we have been researching and doing proof of concept visualizations working with a number of Business Analytics companies. Clearly Operations was biased when the decision to build our own BI tool was made.
If you are developing your own data warehouse and reporting tools – that is, develop versus buy – then here are a few things to consider:
• The IT Department will estimate the time to program new reports and Dashboards. The management team will need to factor in the time to design and specify reports, communicate these needs to the development team and then test and validate reports once completed. IT will then need to document business rules and algorithms. Be optimistic and assume that this cycle is required only twice per report. My rule of thumb is to triple the estimated time for development in order to be in the realm of reality.
• Then there are the hidden costs: hardware, software and the staff to specify, configure, and maintain all of this equipment. When figuring out costs, remember that hardware has a useful life of about three years.
• Who will provide support to the internal end users? Who will be responsible for maintaining the database? Who will be responsible for on-going enhancements?
The argument that is often presented is that it is more cost effective to develop in-house – but time is also important. Remember the rule of thumb – triple all time estimates. This increases the cost. Do you know what the fully-loaded hourly cost is for your development team? What about your business analysts? Are you prepared to wait three years for that new Dashboard?
Conclusion
Remember the rule of three – three times the cost, three times the original schedule, and three times the frustration.
Mary Sue O’Melia is president of TransTrack Systems®, Inc., a business intelligence solution that transforms volumes of data into meaningful information for transportation managers and executives to use in planning, strategizing and ensuring optimal performance. Visit TransTrack Systems® at: www.transtrack.net