The Ground Rules for Building Custom SoftwarePosted 2013-03-05 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Here's an account of the decision-making process that led ASD to build a custom software system, with a look at hits and misses and insight into best practices.
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.