The best strategy of avoiding the heartache of building new systems is to shun them by leveraging the plethora of today's off-the-shelf software. Much of the software already in the market includes extensive tools and means for modifying, customizing and personalizing the software to meet your unique needs. While the complexity of some of these systems can overwhelm an organization, custom software projects are often uniquely more dangerous. The creativity and wisdom to produce new software, especially without the reality check of other businesses ("best practices"), is risky.

Deciding that building new software is the only solution should be the culmination of a number of steps:

• Articulate the requirements of a system.
• Identify existing software by reliable vendors (testing the software, checking references, and the like) and establish that your needs cannot be met by any of them.
• Consider the variances from the best practices in your industry and others that may be applicable to your business (as defined by your requirements). Are these the reasons why the off-the-shelf solutions will not work? Honestly ask yourself whether your perceived corporate individuality is vanity masked as competitive advantage.
• Represent all organizational perspectives and include your organizational strategy and future.

Once you are methodically certain that custom software will be the best solution and you already have the foundation for a start, there is still more:

• Choose a development vendor that will likely be around. Talk to references. Establish that there is sufficient organizational depth to continue to receive ongoing services well into the future. 
• Define a governance structure for managing the construction phase. This structure will address authorizations for changes, methods of prioritizing projects or project elements, and even phase completions and acceptance. This is essential in preventing the out-of-control project.
• Set realistic expectations. Realism impacts the entire success of a project. Will the project elements supplied by you be deliverable on time? Is the development time reasonable given the staffing and other commitments of the vendor?

Contracting fundamentals

Custom software requires contracts. As you negotiate with a vendor, the issues extend beyond rate sheets and proposals to specific responsibilities that each side has to a successful project and, in most cases, a long-lived relationship. This contract's importance is no less than that of a contract with an important supplier or customer.

• Have a contract. Have I said this enough? Make sure that it protects you and is fair to the vendor (you do want the vendor to stay in business and to continue servicing you). Also, make sure that it is enforceable – pragmatically and legally. Will you abide by the oversight and governance dictates that it demands?
• Elements that should be in place:
  • Ownership of intellectual property. You are paying for the development, so all work typically should belong to you. Sometimes a vendor will see the opportunity of your creativity as a goldmine for its own further enrichment. This possibility should be addressed even before work begins.
  • Non-disclosure of confidential information and/or trade secrets. Working closely with a partner requires awareness of secrets, activities, and processes that define who you are. Care must be given to protect this valuable data and ways of doing things from being shared with others.
  • Compensation. How will the vendor paid or the project be proposed? How often, at what milestones, and how fixed? Will travel time be billed for? What cost of living adjustments will be made for projects that extend more than 12 months? What recordkeeping and auditability of those records will be kept to document work that is billed for?
  • Non-solicitation of your employees. The vendor should be discouraged from taking good people away from you.
  • Maintenance of the system. Over time changes will likely have to be made to get work completed. Errors are discovered. Needs change. The development vendor will likely have the greatest familiarity to make those changes. Frequency and timeliness of those changes is to be considered.
  • Documentation and knowledge transfer. Crafting your vision is not enough for a project. Defining and describing how the end result came into being is critical. This documentation may use established methodologies or may be primitive, but it must exist for inevitable staffing changes in your and your vendor's organizations. At the same time, becoming too reliant on a vendor can mean that you may not have the autonomy to make the best decisions about the custom software. Too alleviate this risk, becoming familiar with the intricacies of the software during the process of knowledge transfer is helpful.
  • Governance. What is the change order process? What constitutes a change order and not a new project request? What is the feedback loop between vendor, your user, your project champion, and your project authorizer? What methodology is being used for pre-programming and implementation analysis and execution? Answers to these questions should all appear in your contract.

The need for custom software will exist long into the future. For some, this path will lead to failure or frustration. Let's hope when you follow this path, you will be pleasantly surprised as a byproduct of preparedness and process.

More Byte of Success articles

CHAIM YUDKOWSKY, CPA, CITP, is Director of IT for the American Israel Public Affairs Committee (AIPAC) based in Washington, DC. He is also president of Byte of Success Inc., a technology consulting company specializing in helping small and mid-size business grow using technology. He is available for both consultation and speaking. He may be reached at cyudkowsky@byteofsuccess.com.