Need immediate assistance? Text "hello" to +1 218.296.7903
888.756.3617
info@spedsta.com

Considerations when buying, building or maintaining transportation scheduling software

Considerations when buying, building or maintaining transportation scheduling software

Consider the analogy by Alan Cooper (creator of one of the most popular computer languages on the planet) who said “Building a software program is like making a pile of bricks. The pile is one brick wide and 1,000 bricks tall with each brick laid right on top of the one preceding it. The tower can reach its full height only if the bricks are placed with great precision on top of one another. Any deviation will cause the bricks above to wobble, topple and fall. If the 998th brick deviates by a quarter of an inch, the tower can still probably achieve 1,000 bricks, but if the deviation is in the 5th brick, the tower will never get above a couple of dozen.”

Transportation organizations use tools that make the most sense for them and sometimes that choice is developing their own software. As in Alan’s statement above, choosing the right software foundation is the difference between success and failure. If your organization is considering developing ride-scheduling software or if you already have one, then avoid the “house of cards” phenomenon of your software by considering some of the below questions:

  • How to maintain the system if a key software engineer or IT person leaves?
  • How to add new features and services?
  • How can system uptime be guaranteed to 99.99%?
  • How to manage the data so that HIPAA and client confidentiality is ensured?
  • How to protect and secure the system from cyber-attacks?

These key questions address the underlying “build vs buy” choice that organizations face when determining how to run their transportation service. As with everything, there is no single “correct answer” to this “build vs. buy” question. Consider the choice today of building a spreadsheet, word processing, email service, or any other software that we use on a daily basis. This would not be a great choice since Microsoft tools and Gmail are perfectly suitable for our needs at a fraction of the cost of building something from scratch. When analyzing a “build vs. buy” decision, “buying” has some advantages because it can save time, save money, lower risk, and allow internal staff to focus energy on the organization’s core competency. We’ll address each of these issues below:

  1. Save time: The goal is to find the best use of internal resources and expertise when implementing any solution for your organization. Typically your organization’s core capabilities and expertise are in managing and delivering transportation and not in the intricacies of software development and maintenance. By leveraging expertise externally, you allow your internal team to save time and spend it on areas in which you are the best.
  2. Save money: Any solution should be analyzed for the total cost of ownership. Labor costs (whether internal or external) will be needed for both the creation of the system as well as its long-term maintenance. Including the labor costs with the technology procurement costs and looking across a five-year time span will be valuable in comparing alternative approaches. Another benefit of working with off-the-shelf technologies is that it is very inexpensive to get multiple proposals from vendors and compare the five-year costs as well as the feature sets of each approach.
  3. Lower risk: Sometimes in the hectic day-to-day operations of running a transportation service, it takes immense initiative to investigate better ways to solve everyday problems. By using an off-the-shelf product you are taking advantage of a solution that already incorporates industry best practices. Rather than spending time learning all of the best practices and coding them internally, you can evaluate competitive software products and see how the best practices are coded into the product.

Building stuff is fun and most independent contract software developers will love the challenge of building a new software tool for you at a reasonable first-pass cost. It is not wrong to go down that path and it should be seriously evaluated just as any other option in terms of long-term cost, time and expertise. Like planting a fruit tree, the planting of the tree can be pretty quick, but the quality of the fruit comes from an ongoing investment in time and maintenance to make sure you get that shiny apple.