Critical Incident Management

An organization's policies and procedures must govern the interaction between the organization and outside contractors.

Instead of structuring a relationship based on the value of service they are contracted to provide, they base it on the necessity of doing business, as they are the only people who have the source code. In other cases, they have not delivered sufficient documentation for the organization's employees to maintain the system, thereby requiring their continued services. It is essentially a monopoly of one. Because the organization does not have the source code to their custom system, it has lost control of one of its critical assets. Regrettably, this condition is usually brought to the company's attention after it has already happened. The situation grows more desperate as the company is reluctant to notify its lawyers, fearing that the contracted developers might sabotage the source code by modifying it to render it useless at some time. When structuring systems development projects performed by outside contractors, these are a few policy suggestions to reduce risks:

• Get the source code. Be certain to investigate the work history of the contractor, and by all means contact all professional references to ascertain if there were any past problems. The organization must ensure it receives the source code, and there are contractual arrangements with strict requirements to this effect. No excuses are acceptable. The source code must be installed according to the organization's certification and accreditation policies.

• Licensing and documentation. Purchase the appropriate licenses for the source code. Businesses want to replicate the development environment exactly, having the ability to keep the code up to date during the maintenance development phase. Make certain the contractor is drafting the required documentation of effort. This documentation should be subject to inspection and audit by the organization's representatives before the product is delivered. If the organization has the resources, any agreements must permit a representative of the organization to conduct an ongoing review of the code. This inspection must also include documentation.

• Confirmation. Confirm that you are going to receive what you contracted. Force a rebuild of the programs if you are not satisfied. If you have to pay for it, consider it the cost of doing business.

• Secondary plan. Have in the wings a backup developer or other reliable resource familiar with the code base and system design. What if the contractor becomes disabled and is unable to complete the project?

• Ownership and delivery. The organization's policy should require that the contract stipulates who is going to own what. Who owns the software? Does the organization own the software or merely a license to use it? Does the organization own the software to such an extent it may do what it wants with it? Write the contract carefully, and by all means have an attorney familiar with these issues review it before signing.

The best outcome is one of complete control where the organization has its asset with the system working as intended in the event of a problem with the developer. What does the organization have to do in the event the developer fails? Much will depend on the contract's language, your lawyer, and the developer. If you have to go to litigation in order to enforce the contract, you may not have possession of your application, and litigation takes time. By the end of legal wrangling, it is possible everyone loses.