Software development is very expensive, time consuming and risky and should not be taken lightly. Software companies spend years iterating the development to create systems that can be sold and generally accepted into the market. I can’t imagine why any software business owner would develop something that does not meet the market’s general need. If you are looking at on-call scheduling software that requires or even offers large or unlimited customization, you are looking at a vendor who did not develop their software for you, and are trying to squeeze a square peg into a round hole.
Our development philosophy at Adjuvant is to strive to have 80% of the features that our target market customer need to do their job out of the box, without any customization. As healthcare changes, ambulatory practices and hospitals continue to have their needs change around on-call schedule creation and system wide data management. This is a moving target that lends itself well to a web software model that is always developing or modifying to meet the industry needs.
The reason for this approach is that although we recognize that each organization is different, the similarities far outweigh the differences. Many of the differences are people’s individual different styles of working and are not actually true differences. For example, every physician practice that we work with wants tally reports so that they can prove that the schedule that they have created is fair. The tally report is part of the 80% standard, what is different is how people want the information displayed. The reason for this is that most users have spent so many years creating their own system to get their work done that if it doesn’t do it “their way” they don’t want to use it.
This is very similar in other industries as well. For example when the first computerized accounting software was released in 1973, SAP’s software allowed companies to do their purchasing, invoice verification, and inventory management automatically. Although this was revolutionary, most small companies had no desire to make the switch. One of the main reasons for this was that they did not want to standardize their process. Ironically also in 1973 the Financial Accounting Standards Board was created. Chances are if your company went with SAP in the 70’s it was because you were a large company that demanded standardization. You would not want each business unit creating their own process for accounting. Low and behold in 2014 do you know any business that does not use standard accounting software?
Similarly, Astrologers began recording detailed information about their patients’ medical conditions in 1596. Over the next 350+ years physician offices began to create standards for recording patient health information. Although each clinic was different in how it charted, much of the same information was contained in each patients chart. Today when an organization purchases EMR software they are not customizing more than 20%. The EMR Company has done its research and is “tuned in” to its market to know what the majority of their customers need. The point I am trying to illustrate is that the similarities are much greater that the differences.
When it comes to physician on-call scheduling software the situation is similar. Most groups throughout the US, Canada and even places like Australia do things generally the same. The differences come in peoples individual preferences.
Don’t get me wrong, there are some very compelling reasons to make some customizations, such as;
- You can modify any feature you wish
- You can dictate special lay-outs, forms, color, and button placement
- You can make things look and act like the “old way”
There are also some major things to remember about customization, such as;
- Customizing features for an admin-staff member who may leave or change positions down the road is risky and expensive
- Custom development takes a considerable amount of time and money to scope and create requirements
- Custom development takes time to develop
- Custom development takes time to test
- Custom programming is very expensive and often requires re-do’s
- Custom programming typically requires custom support
- User needs and preferences change over time making customization irreverent
- The process you are customizing is unlikely able to be used by other departments
- You lose the ability to cross train schedulers among multiple departments
- The ability of your vendor to say “that’s just what you asked for”
Take the time to find the similarities before you find reasons to customize. Demand that your staff do things the way most others do it in your industry, even if that means change. Standardized processes are developed for the good for the organization, nor the user doing the work.
Key Takeaway: Choose an on-call software vendor that has created and followed the industry standard features. There is no reason to reinvent the wheel and build your own software when general software is widely available. Any more than 20% customization is too much in my opinion.