The person given responsibility to procure computer software or services
for their company faces a complex and challenging project. Not only must
they understand the needs of their organization, they must seek out and
select a cost effective solution and ensure that it operates efficiently
in their environment.

In most organizations, this demanding task is placed on the shoulders of a
manager, director or vice president who will put together a team of user
and technical personnel to carry out the project.

Many things can go wrong during the procurement process. There are countless
reports of projects gone wrong in and outside the airline business. Here
are a few airline examples.

1. An Australian airline once purchased an accounting package that was
written in a programming language that they didn't use or support. That
mistake cost more to correct than what they spent on the software. The
team did a poor job of preparing their evaluation checklist.

2. A Canadian airline purchased a cargo system from a European airline
only to find that the volumes of documentation needed to support the system
needed language translation. This mistake caused considerable additional
cost and delayed implementation. The evaluation team asked if documentation
was included but left out the step of asking to see a sample.

3. Another airline purchased an accounting system that appeared to be
a match but needed so much customization that the project went 2 years
behind schedule and 1 million dollars over budget. The team leader was
pressured to make a decision by senior management, ignored warnings of
potential cost overruns and disregarded recommendations to look at other
solutions.

In order to avoid such misfortunes your team must have someone with an
understanding of what problems can occur and how to address them at each
stage of the process.

UNDERSTANDING NEEDS

Once you identify a need for a solution, you have essentially started
the procurement process. The process should be managed as a project with
well defined milestones starting with the most important document as its
foundation; the Requirements Document.

THE REQUIREMENTS DOCUMENT - KEY TO A SUCCESSFUL PROJECT

Your first milestone is the preparation of a clear requirements document.
Among other things, you must articulate the processes and problems with
the current situation, the desired solution and the benefits to your company
in delivering the new solution.

The Requirements Document is the foundation for; 1. your Business Case
to senior management for project funding and approval, 2. your communication
to potential suppliers of what you need via RFI's and RFQs, 3. the Checklist
to be used during the supplier selection process and, 4. the basic criteria
for contract Acceptance and Deliverables.

If you start talking to suppliers without dedicating serious effort to
the Requirements Document, your chances of effectively managing a successful
project are greatly diminished. Communication with and input from all
the departments involved is an essential step in writing a meaningful
requirements document. User groups, technical specialists and managment
must collaborate at the beginning of the project not after the software
or services have been delivered to assess whether what you purchased can
be salvaged to work for you.

Both the Buyer and Supplier benefit from the information presented in
a well defined project requirements document. Suppliers appreciate knowing
as much as possible about customer requirements so that can assess the
"fit" with their ability to provide a solution.

RELATIONSHIP MANAGEMENT

Your company is about to spend a lot of money in a relationship with
a supplier that will last for as long as you continue to use the selected
software or services. How do you make it a lasting and mutually beneficial
relationship?

Your relationship with the supplier starts with the first contact made
by you or your staff that resulted in an exchange of information about
your needs and how their solution might fit your needs. It might have
started with a look at a supplier's web site, a meeting with a supplier
at an industry meeting or a directive from senior management to look into
a supplier.

As with any relationship, you're going to experience stages. Let's call
the first the "romantic" stage. Here, for a variety of reasons
- usually a desire to expidite the process and get on with your own work
- you and your team "see what you want to see" and become enamoured
with the product, the service or sales pitch. Many a contract has been
signed based on impressions formed during this stage. These contracts
have the most potential for post-purchase problems.

Caution and patience must be exercised to prevent a rush to selection.

In a software sale you may be sold on the "GUI" only to find
after delivery that there is no substance to the code behind the GUI to
support the application. Six months later you've spent twice the license
fee on customization.

In a services agreement, you may develop a rapport and confidence with
the principals of the supplier only to find that the contract doesn't
specify them as the key personnel looking after your needs.

Not to be too negative, there are plenty of success stories resulting
from decisions made in the "romantic" stage, but most managers
will admit an element of luck and a sigh of relief at some point post-purchase.

The next stage, is the Conflict/Power Struggle stage when further evaluation
triggers warnings that cause you to question if the product or service
is what you thought it was in the "romantic" stage. Here starts
the identification of differences and negotiation.

The next stage is Stability. Here you may be working with a shortlist
of 2 or 3 suppliers and you the supplier focus on working together and
develop a better understanding of how the product or service will fit
or work in your environment.

Commitment is the next stage. You're ready to finalize your evaluation
and make a selection of one supplier. Here you'll see a contract, continue
the negotiation and start to take more responsibility for making it work.