Every IT group has dealt with software installation issues at one point or another. Users will always attempt to install software on their business computers, and IT personnel are put in flawed situations dealing with contraband software.

Unfortunately, many organizations have antiquated software policies that aren’t equipped to address these issues fully. Such policies don’t take into account the accessibility of software via the Internet, e-mail, and the popularity of home computing.

Every software installation policy needs to address these key issues:

  • Who is responsible for installing and supporting software?
  • What types of applications can exist on corporate machines?
  • How is licensing handled?
  • How do you address a software need?

In this article, we’ll provide the specifics on drafting a software installation policy that takes these issues into account. We’ll also discuss how you can gain support to make the policy enforceable and ongoing. You can download our sample policy to use as a guide as you develop your own policy.

Who is responsible for installing and supporting software?
A software installation policy needs to address the fact that the IT group is responsible for deploying software to computers. The wording of this section should describe the general methods of installing software on client computers. This can be used to guide the IT group internally for decisions on client clone images, software strategies, and upgrade paths.

However, users could be involved in the installation procedure. An example would be a step-by-step installation procedure and software media sent out to a user in the field or to a telecommuter.

Supporting software is as important as installing it. Before any application goes onto a client computer, some amount of testing should be performed to ensure that it will adequately address the business need and cooperate with the rest of the computing environment in an ongoing manner.

What types of applications can exist on corporate machines?
Keep a list of software needs within the policy. Supplement that list with specific titles and version(s) of the titles. The policy should state who has the ultimate authority for software that is used. In many cases, that could be a team of people from more than the IT group. User input is more of a factor in some software situations than others but should be balanced with IT feedback.

Also address how the applications are to exist. This may be more of an IT-only issue, but it should be addressed in the policy. I feel that software should exist in the following ways only:

  • Part of a clone image or OEM image
  • An IT-drafted step-by-step installation procedure identifying installation options
  • A shortcut only
  • An automated installation through a deployment tool
  • A terminal or Citrix application
  • Some other controlled and documented distribution method

By requiring software to exist only in this manner, IT will have a much better idea of what is supposed to be on the client machines.

How is licensing handled?
IT understands the priority of software licensing, and it should be addressed in the policy. Non-IT people may not understand licensing issues and the associated costs. Software is an expensive tool, but it’s an integral part of doing business. The policy should state who pays for which software licenses. A general model holds IT responsible for the costs of the desktop operating system, productivity tools package, groupware and its corresponding server, the network operating system, and possibly an ERP package. This model would pin the costs of specialty applications to the workgroup that the package serves. This totally depends on the requirements of your organization.

How do you address a software need?
A key to the policy being followed is an easy method of requesting software for a business need. In most IT groups, a phone call or walk down to the IT department will probably get the need addressed, but that is also how licensing can get out of control. IT groups today can create standardized methods of addressing needs for software. Tools such as a company intranet with a software request form, call center software packages, database macros, or even an e-mail form can allow IT to log the pattern of requests and track software installations for licensing. This is important because analyzing needs can enable IT to make better decisions in future software planning. For example, it may be a better decision to put a specific software title on a “clone” image or part of a standard installation set when you balance the cost per seat and the hassle of installing it frequently.

Three keys to concise software policies that work
These areas are key to developing an effective policy (as well as any IT policy):

  • Make the policy directly applicable to your organization.
  • Get management to support the policy.
  • Revisit the policy and be diligent in revising it.

Make the policy directly applicable to your organization
The IT software policy needs to be specific to your organization and target direct situations that occur frequently. A watered-down copy of another organization’s policy will lack substance and effectiveness.

Get management to support the policy
As with any policy, a software policy will need support from management to deliver enforceability. Start at the top; get the CEO or general manager to realize that the IT software policy needs to be enforced. In addition, work with human resources to help refine the policy and even deliver a hard copy of the policy and a briefing to employees as part of their orientation.

IT policies are of interest to management groups. The threat of what could happen if policies are breached becomes an important selling point in getting management to support them. Below are some key points to sell management on supporting a software installation policy.

  • Performance: We provide the technology to let users accomplish the business objective. Any aberration in that environment hinders the ability to accomplish the goal. Whether it is a system performance decrease, security lapse, unnecessary bandwidth consumption, or an inherent time waster, performance changes outside of IT can adversely affect the business objective of technology.
  • Property: The technology we provide (software and hardware) is the property of the organization and is usually purchased by the IT group. The IT staff maintains that property to serve the business objective.
  • Risk: User actions can expose the organization to risk. Two primary examples of exposed risk are:
    Virus infection: The Internet, interaction with home computers, and foreign media can open up unprotected channels.
    Legal issues: Illegal software brought from home, borrowed, or downloaded from the Internet can be very costly if an audit occurs.

Revisit the policy and be diligent in revising it
A key failure of many policies is to let them become stale. IT is fortunate that it can update a policy and push it out easily through technology. A policy needs to be a living document with core principles remaining the same through its period of enforcement. However, the policy should be updated regularly to adapt to changes in the IT environment.

Avenues to address updates to a policy
You should adhere to a specific plan when implementing updates.

  • Make provisions for changes in the policy and determine who will make them.
  • Set a monthly reminder in your groupware package to ask you if there are any changes or new situations that need to be addressed in the policy.
  • E-mail the policy (or possibly the changes) to all users periodically or post the updates on your intranet and notify users when updates occur.

IT should be proactive about the risk that is present with software installations on company computers. Simple tasks can allow IT to have the upper hand in dealing with these issues as they occur or even before they occur. There are tools to use, choices to make, and easy notification actions to take that will help you protect the company computer. Some examples include the following:

  • Utilize security policies on Windows-based computers either as a native feature of Windows or by using a third-party package.
  • Remove or choose not to purchase CD-ROM drives on company desktops unless they are necessary.
  • Use specific cloning procedures to immediately roll back to a known software environment using Norton Ghost, PowerQuest Drive Image, Sysprep, or a similar tool when the environment has changed outside IT.
  • In a Windows environment, use a simple copy operation of all .lnk (shortcut) files from the desktop and Start Menu subfolders to a network resource. In a login script, you could be crafty and make the login script resolve the computer name from the registry, make a directory of that name, place the shortcuts there, and review the contents, periodically looking for aberrations from the desktop standard.

The software policy assists the organization in achieving its objective
Management of the client computer is a critical area for measuring the success of an IT group. Having the client computer in a controlled environment can allow you to be most responsive to changes in your organization. And an enforced software policy can be a key to reaching your client environment utopia.
We look forward to getting your input and hearing your experiences regarding this topic. Join the discussion below or send the editor an e-mail.