When faced with the need for new software packages many companies like to consider the merits of building their own system as well as looking at the available software on the market. There is a big initial appeal to building a bespoke system 'in-house', with all the advantages of the system being exactly designed for the company's needs, and having complete control over the system's future development. It is also an easy decision for management to make, in that there is no need to spend a big chunk of money up front, so the initial impact on the company is reduced.

However there is a lot more to this decision than meets the eye, especially for the more sophisticated packages such as customer relationship management (CRM) systems, where experience shows that a bespoke solution is rarely the most cost effective solution or necessarily realistically achievable within a reasonable timescale.

Some of the key areas to consider when making this decision are outlined below:

• Development time

  Most common types of software packages are by now quite well developed in their market places: i.e. there are a number of well-established packages in each area covering a good range of market requirements. Many of these packages have been developed over the last 10 or more years and have had a team of developers working on them, totaling many hundreds of man-years of development time.
  

  Therefore in order to end up with a smooth running system, which is rich in functionality and good-looking enough to encourage your staff to use it, will probably take a huge amount of focused development effort over a significant period.



• Forgotten functionality

  In thinking through the process of this development for a CRM system, some areas of functionality typically get forgotten. It is common for an in-house system to be developed with no functionality for users to work on the database remotely and synchronize back changes to the central office. Since CRM is largely a sales tool, the moment sales people are out on the road their use of the system is severely restricted. The development of a remote synchronization tool for a CRM system is one of the most complex areas, and without it the information in the system can easily become out of date and therefore useless. There is no point in expecting sales people to save up changes till they return to the office; they are typically not the type of person to remember to do this and they will never find the time once the moment has passed.

  Similarly when companies grow there is usually an increasing need for security restrictions, both to hide confidential information and to prevent users making changes in parts of the system they don't understand. This is again the type of complexity that is easily forgotten, and yet without which the system can be damaged. Consider a common example of a bulk update facility in a CRM system: if a user gets into this tool and unwittingly makes a change without understanding the consequences, large quantities of information can be wiped out at a single keystroke!

  It is important therefore to make sure all these peripheral features are designed and costed into the original system specification or the system may end up being discarded because of unsolvable practical issues.

• Lack of functionality

  Requirements are often complex and organizations that choose to build their own systems must accept that this comes at a high price. Cost is a significant barrier to the functionality that is required and companies must therefore decide whether to build the required complex functionality despite the cost or reduce application functionality to meet budget constraints.

• Customization

  Most commercially available CRM systems include the facility to do extensive customization to fit an organization's requirements. Often there are also packages which can be linked to the core system to increase its functionality. If the customization facility is used well it can radically change the system and can open up a wide range of possibilities. These options should be considered carefully even to the point of doing a mock-up of the proposed system. Often the decision to build rather than buy is driven by a lack of understanding of the range of possibilities available to the company.

• Product / Scope Creep

  Organizations that internally develop CRM applications run the risk that the project's initial scope will increase after the design stage to incorporate additional functionality. This product specification creep needs to be handled carefully within any organization, but commercial software houses make their business by understanding and responding to the demands of the market place and controlling undesirable creep. Organizations who write their own system and don't appropriately control product creep end up with a spider's web of a system that nobody understands leaving a nightmare for any future development.

• On-going support costs

  
  When the total cost of ownership of systems is calculated it is found that ongoing maintenance costs are far higher than the initial cost of development. All commercial suppliers offer support and upgrades as part of the package, and the cost of development to keep the product up to date and bug-free is shared across the entire user base.

• Human Resources

  Internal development of a CRM application requires a sustained and dedicated effort by a broad variety of employees and managers. Given that such packaged applications such as GoldMine are available, companies should seriously question the wisdom of dedicating their most precious IT resources to the long-term development of solutions that they can readily license.

• Architecture

  Choosing the right platform is essential. Many companies considering building their own system will choose a platform such as MS Access simply because it is readily available and one that their developers are familiar with. However CRM systems are actively used and the database size grows very quickly. MS Access or similar databases are not able to cope with the data traffic above around 15-20 users. Most commercial packages will provide upgrade routes for their customers up to larger databases as they require them, but an 'in-house' built system would have to be rewritten from scratch to accommodate company growth.

• Documentation

  For a critical package such as a CRM system it is very important to fully document the design in order to enable future support or development of the system. This is a time consuming exercise and in many cases gets overlooked by the development team. It is especially difficult to achieve this when there are many other pressures on the team. All commercial systems have to be documented in order to secure their future development and sales.



• Higher Deployment Risk

  Commercial systems such as GoldMine are customer proven with over 100,000 companies and 1.2 million users worldwide, this type of commercial package costing a few hundred pounds per seat therefore has to be considered very seriously against an argument to build a system from scratch. If you cost out the developers' time at reasonable commercial rates it will be extremely difficult to achieve even the simplest package within the cost of installing a system such as Goldmine.