The Ground Rules for Building Custom Software
By Michael Castiglione
Businesses cannot compete in today’s market without the right technology, but the right technology is not the same for every company.
The path to deciding what solution is best for a company is not always clear. For some companies, off-the-shelf or customized software platforms are the right fit. For others, a custom software solution has to be built from the ground up.
That was the case at Automated Systems Design, which manufacturers, installs and maintains information transport systems. We have a full-time staff of approximately 30 employees, with more than 12,000 authorized ASD installers and hundreds of customers—all of whom are also users of the company’s software.
As operations manager of ASD, I was asked to manage the company’s development of a custom software platform. Here is an account of the decision-making process that led us to build a custom software system, a look into our hits and misses, and some insight into best practices and lessons we learned along the way.
Initially, the leadership team of ASD did not set out to build a custom software platform. The team—composed of Bob Eskew, CEO; Kevin Kiziah, president; Evelyn Stephens, accounting manager; and me—began by listing requirements for the software platform. Then we reviewed existing ERP off-the-shelf software platforms to see whether they aligned with our requirements.
However, we found that many of the systems that provided the level of functionality we needed for one area of the business, such as project management or logistics, did not include systems for customer relationship management or accounting. When we did find a system that could handle all the different areas of our business, the system was strong in one area of business and weak in the remaining areas.
We found ourselves forced to decide whether to install individual robust systems that were not easily integrated or to install a single ERP system that focused on a specific area of business without the necessary functionality to fully support the other areas of our business.
After evaluating all the options available on the market and not finding a suitable system, the ASD team decided to move forward with the development of custom software, which was eventually named OMNI. The title suggests that the system is designed to be “all-knowing,” connecting all of our business information and making it visible to users.
One of the most important best practices we used was to establish requirements before evaluating our options. By setting out a detailed list of requirements as the first step, we were able to avoid being dazzled by the bells and whistles of software platforms that might not be the right fit.
Before we began developing our custom software, we evaluated our company’s internal resources to see whether we were prepared to manage the development of OMNI. We realized that we did not have all the skill sets necessary to build a custom software platform internally.
As a result, we had to evaluate what external resources were available to outsource the development. We learned that there are different levels of involvement when it comes to developers. Some developers simply write code based on the requirements you give them, while other developers play more of a consulting role to provide strategic advice and guidance. We realized that we needed a developer that would provide us with guidance and advice—not just write code. This proved to be a wise move.
Balancing employee involvement in the process has been a challenge. We wanted feedback and suggestions from employees who would be using the software, but we wanted to avoid having “too many cooks in the kitchen.”
To help control the flow of feedback and suggestions, we set up an electronic submission form for employees, which allows us to have a formal process for evaluating employee suggestions and feedback in an orderly manner. Thus far, employees have submitted several hundred suggestions. We have incorporated many of them into the design of the platform, and we are continuing to evaluate new suggestions and feedback.
Taking a Phased Approach
Looking back, we are glad that we implemented the software through a phased approach instead of an all-at-once approach, which would have been disastrous. The phased approach has given us the ability to invest the time necessary to make the software platform a success and not cut corners.
It has also allowed employees to learn how to use the new system in a test environment instead of being forced to use it in a live environment with the pressure of real-world deadlines and projects on the line.
Building a Flexible Schedule
As we moved forward with building our own software platform, we knew we were moving into uncharted territory. We didn't have the collective learning curve of 10,000 users. Instead, we had to figure out solutions based on trial and error, which has been a challenge.
A lesson we learned is that developing your own software will likely take much longer than you think. As a result, we have had to adopt a flexible schedule that allows us to roll out features as they are completed, instead of setting hard deadlines that we may or may not be able to meet. It can be a challenge working around a flexible schedule, but we help set expectations by clearly communicating progress to stakeholders on a frequent basis.
We did a significant amount of whiteboarding to plan the project, but we later realized that we should have done more. If you don’t spend enough time in the whiteboard room, it will show up later.
Elements that we didn’t include on the whiteboard later showed up as unexpected issues that we had to deal with on the spot before we could move forward with the project. It would have been more productive to invest additional time in whiteboarding to avoid the pop-up projects that showed up down the road.
Too Much Too Soon
Even though we took a phased approach, we still tried to do too much too soon when it came to adding features. We fell into the trap of wanting to overdesign the first screens and modules. We tried to take a big swing and hit a home run with the first iteration.
We have learned that we have to follow the lead of software companies and start with the basics and add additional features in future iterations.
Overlooking the Obvious
When you build a system from the ground up, you have to make decisions about every element. This level of detail caused us to overlook some of the basic features we took for granted in the old system.
For instance, pop-up windows were automatic in the old system, and we didn’t think to add them to the new system until users complained about having to switch back and forth between screens. In a project of this size and scope, it is easy to overlook simple features such as pop-up windows.
Developing a software platform is an expensive, time-consuming process. For this reason, we recommend researching the available off-the-shelf software options before developing a custom software platform. If there is a system on the market that can meet your needs, start there. You may not need to develop your own system.
If a system on the market meets most of your needs, but not all, see what customization options exist before you decide to build software from scratch. If no system on the market meets your needs and none can be customized to meet your needs, it might be time to consider building a proprietary system.
Looking back, we realize that we made the right choice for ASD by building a custom software platform, even though the process has not been without challenges. OMNI has helped us integrate all areas of our business so we can focus on what’s important to our customers.
Through the OMNI platform, we have been able to increase efficiency and improve customer service, and we plan to continually improve the platform over time to further improve operations.
Michael Castiglione is the operations manager of Automated Systems Design, which manufactures high-performance iCAT-ITS copper offerings, as well as iGLO-ITS fiber optic products. www.asd-usa.com