|Guide for Software and Services|
The Sales Cycle
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.
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.
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.