With the release of OS X, business owners have realized a tremendous ncrease in the number of pre-built applications (many ported from the UNIX world). Even with this increase, companies sometimes find it difficult to switch to the Mac or run their business entirely on Macs because of one or two specific applications are available only for Windows.
Companies are hesitant though to consider custom solutions though because of fears regarding costs, support, and development time/effort. These concerns often overshadow the tremendous benefits of custom solutions. To better understand these issues, we examine each in more detail.
Development time/costs
The overwhelming concern for most people is the cost and time commitment required to build a custom application. Many of these fears come from past personal experiences in which a project that was estimated to take a few weeks and cost a few hundred or thousands of dollars, wound up lasting months and costing tens of thousands.
In the past, this was a legitimate concern because the tools often required very specialized skills and much of the work had to be done from scratch. Each project required that developers rebuild everything from program logic to user interface. However, modern software development tools make much of this process easier. Many tools trivialize the process of building a UI, leaving more time for the developer to focus on the core program logic. The result is faster development times, and applications with better underlying logic. While many such tools existed for OS 8/9, the release of Mac OS X has resulted in a tremendous increase in the number and quality of such tools.
These advanced tools span the whole spectrum of development efforts including stand-along applications (InterfaceBuilder, RealBasic, CodeWarrior, and a myriad of other tools), databases (Filemaker, 4D, MySQL, OpenBase, PostgreSQL, ), and web development (WebObjects, Java, XML, PHP …). Everyday, new tools are announced for OS X, all with the intent to make applications development easier.
Even with all these tools, there are obviously still risks. Many projects fall behind schedule not because of the tools in use or the skills of the programmer, but because they are poorly scoped or managed. Proper scope and management is critical to the success of any project. Even when buying off-the-shelf software, poor planning and execution can ruin the value of the software implementation or drive up costs significantly.
Business owners may still be hesitant, thinking that the volume associated with off-the-shelf software always results in a lower implementation price. While it may appear to be less expensive upfront, off-the-shelf software lacks one thing, the ability to truly integrate into your business processes. With off-the-shelf software, you may find that you have to change some of the ways you do business because the software cannot meet 100% of your needs. Off-the-shelf software is designed to be generic. Software that offers customization capability usually comes at a higher price, and often offers little in the way of customization of the underlying program logic. Most customization is limited to UI tweaking and simple workflow rules.
With custom software, you can mold the software to fit your business processes (this is often a good time to review those processes and make sure they are efficient and effective). Software is supposed to be a tool that makes your business run more smoothly, not something just layered in as a data capture tool.
Obviously, there is probably a “sweet-spot” in the decision-making process. A project that is too small may have difficulty in overcoming some of the basic overhead costs of initiating a custom software project. Large projects may have a tremendous amount of underlying workflow and business logic that requires a significant amount of upfront design. Large projects may benefit from using off-the-shelf software that offers a high-degree of customizability (these are often frameworks or quasi-development tools that are designed for a specific market segment and they of course come at a price).
Resourcing
Once you make the decision to proceed with a custom software project, the next step is deciding if you want to do the development in-house or outsource to a third-party. This decision is best driven by three factors – company size, core competencies, and timelines.
Small companies will not have the staff on-hand to handle anything but the smallest of projects and thus are forced to immediately consider outsourcing the project. Hiring someone and teaching them your business is time-consuming. It would be faster, in most cases, to identify a company that already caters to the same market segment, and work with them. They understand your industry, making it easier for them to learn your specific business processes and tailor a solution to meet your needs.
For larger companies, the next question is does the project make sense given the core competencies and strategies of your business? Even if your company already has a few IT support people on staff, their skills may not be in doing software development. While it would be great to offer them the opportunity to learn these skills, the reality is that it would only draw them away from their other responsibilities and potentially affect your core business operations. The other factor is that building software takes more than just a software coder; you need people to manage the project, handle quality assurance, and analyze business needs. Building a team to handle all these tasks takes time, and when added to the time employees need to learn the development tools, potentially make a project drag-on much longer than desired.
Another risk associated with using inexperienced in-house software developers is the probability of making poor technology and design decisions during the learning process. Someone new to database development may make mistakes early in the design that lead to a major data integrity issues or major re-work at a later date. The former may only crop at inappropriate times as users try to use the tool and find that it is ineffective in managing the business. The latter just drives up development costs.
If you decide to outsource, the method will be driven by the third factor, timeline. You have two options, hire contractors but use internal staff to design and manage the project. The contractors are under the control of internal employees who have oversight over the entire project. The other alternative, outsource the entire development project. In this scenario, an internal employee (or small team) works with an outside party to define the project scope and requirements, but project management, development, and testing are all done off-site. The outsourcing company brings forward completed versions of the application at very stages for review by the internal team.
How do timelines affect this decision? With in-house project management, more time is needed during the project initiation phase, as in-house project managers and business analysts are identified, and outside contractors hired. Some training may also be required for the in-house staff. With complete outsourcing, you can identify a company that has all the needed resources upfront, and who can start on the development process much faster.
Of course this decision, also brings us back to the issues of core competencies. No matter how many employees you have, it may not make sense to handle the management of a technology project, especially if it is to be a one-time effort. If no one in your business has any experience managing an IT project or any long-term interest in managing such projects, you should consider full outsourcing as your only option.
Support
Even when people get past the cost issue, they still often get stuck at understanding the long-term implications of support. The easy answer is that off-the-shelf software has a large company backing it that can offer support and bug fixes. This answer fails to consider the realities of modern software support.
How often have you been irked by the support a company offers for their products? Companies are cutting back on support regularly, charging customers for basic software support and abandoning older versions forcing you to upgrade.
Support really comes down to two things – documentation and testing. Most of the documentation offered with off-the-shelf products is abysmal. Leaving users struggling by, looking for support in discussion forums, third-party books, and user groups/communities. Documentation is an after-thought for most commercial applications. Why? Because poor documentation means more money for the company through the sales of software support contracts which allows users to call and get answer to basic questions. Also, customers cannot evaluate the quality of documentation before buying the software in most cases, meaning that the quality of the documentation has little impact on sales. The same applies to testing. The focus in the software industry is on delivering new versions/features to drive upgrade revenues. Spending a lot of time testing code does not materially affect its eventual sales (especially for applications well-entrenched). This isn’t to say that companies do no testing, just that testing is often viewed as a hindrance to product release and relegated to basic sanity testing.
Of course, customer software may suffer from both of these problems, but you have more control to prevent this. First, documentation should be a key requirement of the project definition. Second, if a company delivers poorly tested and buggy code, you have options for recourse. Make sure that when you negotiate your contracts you include terminology to cover both documentation and quality requirements. Insist on reviews at regular intervals to ensure that the developer is taking these requirements seriously and meeting your expectations. With customer software you have a say in the quality of the application and the most common reasons for failure are poor planning and poor project oversight.
As for long-term support, you may be concerned about what happens a few years down the road when you decide to upgrade the application. Obviously, picking a well-established company is one crucial component, but again documentation is key. Make sure the documentation included with the project not only covers using the application, but also explains the underlying code and methodologies. If you have to, consider having a third-party review the documentation for you to ensure that it is complete and thorough.
Summary
Discussions about the merits and pitfalls of custom software could extend for days; the reality though is that custom software development is a viable option for many businesses. Custom software can be better integrated with business processes, has the potential to be cheaper over time (and offer a much better ROI), and is often of higher quality. Getting it right though takes work and commitment. You cannot just say you are going to build a new customer database and start hacking away at Filemaker, expecting to build the next great CRM (Customer Relationship Management) tool. Custom software development takes the right combination of planning and talent. Now is an ideal time, with the slow US economy there is a ready pool of talent, and business is slow, giving business owners an opportunity to evaluate processes and improve their efficiency and effectiveness.
First appeared at The Business Mac
Paul Shields is currently working as a network software
developer/tester for a small telecommunications company in Dallas. He
is also the senior editor of The Business Mac, a site dedicated to
Macintosh Business owners and founder of tbmconsulting, a software
development company that specializes in web-based business process
applications.
