Software Procurement Policy

Software Procurement Policy
By Scott Matteson • June 2014
Copyright ©2014 CBS Interactive Inc. All rights reserved.

Software Procurement Policy Credits
Copyright ©2014 by CBS Interactive Inc. All rights reserved. Global Editor in Chief
Jason Hiner
Tech Pro Research and its logo are trademarks of CBS Interactive Inc.
All other product names or services identified throughout this book are Editor in Chief, UK
Steve Ranger
trademarks or registered trademarks of their respective companies.
Managing Editor
Published by Bill Detwiler
Tech Pro Research June 2014
Editor, Australia
Chris Duckett
Disclaimer
The information contained herein has been obtained from sources
Senior Editors
Jody Gilbert
believe to be reliable. CBS Interactive Inc. disclaims all warranties Mary Weilage
Sonja Thompson
as to the accuracy, completeness, or adequacy of such information. Teena Hammond
CBS Interactive Inc. shall have no liability for errors, omissions, Chief Reporter
Nick Heath
or inadequacies in the information contained herein or for the
interpretations thereof. The reader assumes sole responsibility for Staff Writers
Lyndsey Gilpin
the selection of these materials to achieve its intended results. The Conner Forrest
Erin Carson
opinions expressed herein are subject to change without notice.
Graphic Designer
Tech Pro Research Lorraine Vogel
1630 Lyndon Farm Court

Suite 200
Louisville, KY 40223
http://techproresearch.com
Visit: Site Help & Feedback
Tech Pro Research is a ZDNet Web site.

3

Summary
Procuring software packages for the organization is a complicated process which involves more than just technological
knowledge. There are financial and support aspects to consider, proof of concepts to evaluate and vendor negotiations
to handle. Navigating through the details of a request for proposal or RFP (a document supplied by vendors to answer
questions and provide information about their products) alone can be challenging for newcomers and seasoned
professionals alike. Writing the check is the easy part; it’s the evaluation and decision-making process beforehand
which usually requires the highest investments of time and analysis — and demands thorough coordination among
stakeholders in the project.
Having a strong software procurement policy will enable your organization to facilitate and streamline purchasing,
reduce risks or inadequate decisions and help adhere to predictable standards that can be consistently applied to mul-
tiple endeavors. This Software Procurement Policy covers the following components of software package procurement:
Software evaluation
Vendor screening
RFP process
Vendor candidate evaluation
Proof of concept
Contracts and purchasing
Vendor management
Purpose
The purpose of this policy is to help the IT department ensure that all necessary information is collected and assessed
when reviewing software packages in order to make the most qualified purchase possible. It also includes software
purchasing guidelines to identify roles and responsibilities.
This policy applies both to traditional client-based software products such as Microsoft Office and cloud-based
“subscription” or external services such as hosted email or online document collaboration products. “Software” is
defined here as “local or remote applications which are used by the business to conduct company operations.”
Note that this policy is designed to apply to company-wide or large-scale software deployments; one-off purchases
such as Adobe Photoshop for a single designer or Siemen’s Fibersim for an engineer are not necessarily bound to this
policy, but are left to the discretion of the IT department and/or purchasing personnel as needed.

4
Scope
While this policy is primarily designated for IT staff, all full-time employees, contract workers, consultants, part-time
staff, temporary workers and other personnel are also covered by this policy.
Exceptions
There are no exceptions to this policy except where permitted otherwise in writing.
Software purchasing guidelines

All requests for software purchases, whether small-scale individual items or company-wide endeavors must be sent
to the IT department in order for them to process the request and prepare the project according to this policy. These
requests must be accompanied by a valid business case demonstrating the need for the software and the expected
results/benefits.
Where applicable, the Office of Security should be consulted to ensure the product is appropriate for use in our
environment and there are no vulnerability or exposure concerns.
The IT Department has the sole responsibility for placing orders for company software/services (working with
purchasing personnel where applicable). All software purchases will need to have full approval and authorization prior
to deployment.
The IT department will maintain contract and support details (where applicable) for all software products and arrange
renewals as necessary.
If the software request is declined or changed, the IT department will notify the requestor of the details and reasoning
behind this decision.
Software procurement requirements

Every software procurement project should begin with a “kickoff” meeting comprised of product stakeholders. This
project group must include representatives from the following areas:
The IT department
Purchasing staff (where applicable)
Managers of employees who will use the product
Employees of different backgrounds and disciplines who will receive the software (for instance programmers,
data science analysts and database administrators)

5
The kickoff meeting should determine goals, requirements, the scope of the product (where it will be used and what
its purpose will be) and an acceptable budget. The following topics will then be addressed and scheduled on a project
roadmap.
1. Software evaluation
A software evaluation team must be established in order to build a test plan including analysis of the software
requirements and methods to ensure potential products meet these needs. The team should be representative
of all groups who will use the final product. An evaluation plan should be built with a proof of concept in mind.
Candidate packages for evaluation will then be determined and narrowed down to a workable number of choices
via the next three steps.
2. Vendor screening
A vendor questionnaire checklist should be used by company staff to help determine suitable product candidates.
The checklist should be based upon the software requirements. For instance, if the goal is to determine a
document collaboration vendor a list of capabilities should be gathered such as shared file access (multiple edits
from several users at once) and email notifications when key files are updated. The checklist can then be used to
apply to all vendors offering solutions in this category.
Rejected candidate packages should be documented in order to demonstrate why they were eliminated from
the project. The project group will then evaluate the remaining packages to ensure they adequately meet the
appropriate criteria to proceed.
3. RFP process
Once a list of suitable vendors has been obtained, the request for proposal (RFP) process begins. This involves
contacting each vendor and arranging to submit to them a list of questions regarding the business, their product
and their support/financing/licensing details. Vendors should be informed that an evaluation or proof of concept
of their product will be part of the selection process.
Some RFP questions will be universal and include such examples as:
“What is your company name, address, website and main phone number?”
“Please list the primary point of contact for your company and include their name, e-mail address and phone
number.”
“How long has your company been in business?”
“Please provide a brief history of your company.”
“Please provide financial information regarding your organization’s cash flow and profitability.”
“What is your company’s core competency?”

6
“How many customers do you have?”
“What percentage of your customers renew their contracts?”
“Please discuss ROI in relation to your product solution.”
“How many product updates/upgrades do you release in a year?”
“Is your licensing concurrent user or by named user?”
“What is your pricing and subscription model?”
“What percentage of your customers are on your current release?”
“Please provide three references including: Name, Title, Company, Contact Information, number of
employees, and term of contract.”
RFPs should also include the following items:
Proposal instructions
A system requirements model
A description of the operational environment
Performance standards for the product
A milestone schedule for deployment
Company/vendor responsibilities
Proposal evaluation criteria
Details on the method of payment
Because RFPs will vary in scope and degree depending on the software packages involved, research should be
conducted into sample RFPs for similar product types. Each RFP should be modeled after available samples,
plenty of which can be located and reviewed on the internet. There should be sufficient information in the RFP
for vendors to provide adequate responses.
Vendor feedback should include design and scope alternatives, as well as an accompanying implementation
strategy and a cost benefit analysis.
The project group and, where applicable, the legal department must concur with the RFP before it can be
submitted.

7
4. Vendor candidate selection

Once the RFP responses are received the project team must review and rank all candidate products. Candidates
will be evaluated from a functional and financial perspective.
The financial stability of the vendor organization should be thoroughly researched and documented. Availability
and competence of vendor support staff should also be assessed. Take into consideration any implementation
factors — will the vendor install the product, will in-house IT personnel fill that role, or will the process be referred
to a third party such as a consulting service?
References from other customers should be reviewed and confirmed in order for a vendor to be deemed
appropriate for selection.
The final recommended package should be that deemed by the project team to be superior in terms of
functionality, costs, risks, growth potential and previously developed evaluation criteria.
Note that some vendors are reluctant to provide software for a proof-of-concept test beforehand, preferring to
sell their products and allow a lengthy window for customers to return the software for a refund if it does not meet
expectations. It will be up to the discretion of the IT department/purchasing personnel as to whether to agree to
this model. If this method is acceptable, it is recommended to negotiate the longest possible return window and
establish dedicated support contacts at the vendor organization to readily address any issues or concerns with
the product.
5. Proof of concept
The project team will ensure there are sufficient material/resources on hand to perform the functional in-house
evaluation. Plans for user participation in the ease-of-use evaluation process will then be determined. Criteria for
success should be defined at this stage as well as the duration of the evaluation. The vendor will then provide the
software for use on a trial basis to confirm that requirements are met.
The software evaluation team will then begin using the product. Functionality strengths and weaknesses as well
as system controls and security must be defined and documented during this stage of the process.
Any major problems that might cause serious obstacles to the installation, use, and maintenance of the package
should be noted. Similarly, any requirements not met by each package must be identified along with any available
alternatives for meeting these requirements. If these problems or unmet requirements are cause for concern by
the project team that the vendor cannot fully satisfy the goals of the software procurement another vendor from
the RFP process should be chosen for another proof of concept.
All reviewers must submit feedback as to the evaluation results so the project team can assess whether the
product is suitable for adoption.

8
6. Contracts and purchasing
Once the decision has been made to purchase the product, quotes must be obtained from the vendor. Software
and support agreements should be negotiated for the best possible rates and renewal timeframes and costs
(if applicable) should be included in this step. Generally long-term commitments for support/maintenance/
subscription plans (for instance, 5 years instead of 1 year) yield better prices, but future company operations
and plans, where known, should be taken into consideration so as to avoid choosing a commitment that will be
too short or too long.
Any proposed contract submitted to the legal department (where applicable) for review. At this point the finance/
purchasing group will handle the payment aspects of the project.
7. Vendor management
As stated previously, the IT department will manage the vendor contracts/support/renewals and should document
the necessary information relevant to handle these tasks. If recurring payments are involved the finance/purchasing
department will be responsible for them.
Specifications for software modifications/updates must be defined during this stage; this includes routine patches
and version upgrades. The vendor should be given all necessary contact information to facilitate future changes to
the software. Impacts to the operational environment must be identified as necessary to support these upgrades;
will they happen automatically or through manual installation? The IT department will be responsible for notifying
users and overseeing these operations.
Monitoring
The organization will monitor company systems and personnel to ensure strict adherence to this policy. Company staff
should understand that all company-owned equipment can and will be subject to scrutiny both via centralized remote
administration and direct access where necessary.
Violations and penalties

Any violation of the Software Procurement Policy should be reviewed to assess the reasoning behind the violation.
Failure to comply with the Software Procurement Policy or any of its tenets could result in disciplinary action leading
up to and including termination of employment.

9
Acknowledgment of Software Procurement Policy

This form is used to acknowledge receipt of, and compliance with, the organization’s Software Procurement Policy.
Procedure
Complete the following steps:
1. Read the Software Procurement Policy.
2. Sign and date in the spaces provided.
3. Return a copy of this signed document to the IT department manager.
Signature
Your signature attests that you agree to the following terms:
(i) I have received and read a copy of the Software Procurement Policy and I understand and agree to
the same.
(ii) I understand the organization may monitor the implementation of and adherence to this policy to review
the results for appropriateness of content.
(iii) I understand that violations of the Software Procurement Policy could result in disciplinary action against
me.
______________________________________________________________________________________________________
Employee Signature
______________________________________________________________________________________________________
Employee Title
______________________________________________________________________________________________________
Employee Name
______________________________________________________________________________________________________
Date
______________________________________________________________________________________________________
Department/Location
Disclaimer: This policy is not a substitute for legal advice. If you have legal questions related to this policy,
see your lawyer.

Software Procurement Policy

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Software Procurement Policy

Încărcat de

Drepturi de autor:

Formate disponibile

Software Procurement Policy

By Scott Matteson • June 2014

Copyright ©2014 CBS Interactive Inc. All rights reserved.

1630 Lyndon Farm Court

Tech Pro Research is a ZDNet Web site.

Copyright ©2014 CBS Interactive Inc. All rights reserved.