The one universal truth is that there are right ways and wrong ways to select accounting software. In nearly all cases I can think of, with the one-person office being the exception of course, the decision process has to be a collective effort. Many individuals should have input into and take responsibility for the overall process. Management must be fully aware of the financial commitment and not fool themselves into cutting corners, or delaying portions of the implementation to a later time. For example, training comes first, not last! And, unless you truly understand your business processes, then there is no way you can implement a new system that can benefit you. The following steps are tried and true. Use these steps as a guideline making changes to fit how your organization works. If a process like the following is used, it should help ensure a high level of satisfaction when the implementation is all over.

1. Establish a Technology Advisory Committee (TAC) – As we have stated, accounting software selection is no longer a one-person task. In larger businesses it is recommended that representatives be selected from multiple departments to participate in a Technology Advisory Committee, or TAC, that oversees the evaluation and selection process. The committee should have no more than 5 to 7 members. For very large organizations, break the group into multiple committees that report up to the primary TAC. Experience tells us that committees with more than seven members become cumbersome and difficult to manage in terms of meetings, schedules and so forth. The TAC should include as a minimum, a senior representative from management who provides guidance and has authority to act, a representative of the Information Technology (IT) Department who mostly listens and advises the TAC as to the economic impact and implications of specific solutions on the technology infrastructure of the organization. The IT representative should be unbiased and offer professional advice without forcing the choice of a particular technology. Ultimately, the TAC must convince management of their recommendations and management must be willing to make the commitment. Rarely is the TAC the final decision body, however TAC members must feel that management will listen to and act upon their recommendations, assuming there is mutual trust and good faith present. If TAC members feel that they are part of a rubber stamp process and their considerations do not matter – don’t waste your time or money. One of the leading issues that lead to costly delays and “failures” when implementing new applications is a lack of “buy in” by the users. The first step in achieving buy in and saving significant dollars on the total project is a knowledgeable and committed TAC.
    
2. Prepare your Needs Analysis – A very basic question is “How can anyone select an application if they do not know what they need the application to do?” Oh sure! I can hear you thinking, “I have been at this job for 20 years, I know exactly what I need!” You may be thinking something else as well! But, that is all I heard. Actually, I hear comments very much like that often. Many users give me a quizzical look when I ask them to list all the things they do, and then separate the list into mission critical (there is an economic impact if the task is not done), and a list of “other stuff”, that would be nice, but has no major impact on the business. Then I ask them to do very simple flow diagrams of how they perform the tasks. When all this is put together you have a rough, but pretty good, workflow diagram of how information flows through your organization. Believe me, this will be such an eye opener that you will go back and do more detailed flows, known as the AS IS, and then begin finding ways to streamline these processes by creating TO BE flows. This is a great time to optimize your business. Take advantage of it. From the Needs Analysis process, you will develop the Requirements Definition, a fancy term for a very important document. The Requirements Definition document defines what your business needs from an application in order of importance. During the Needs Analysis phase you will also gather samples of every form (checks, invoices, picking tickets, etc.), and every report the current system produces. Don’t forget all those spreadsheets and word processing documents you used to supplement your current system. Integrating these renegade systems, those systems outside the system, is important for ease of processing and consistency of data. Ask the hard question “Why?” for every form and report. Decide what is important and what is not.
    
3. Talk with your current vendor – Unless your current accounting solution provider is the problem, it is a good idea to share your issues and needs with them and give them an opportunity to submit a recommendation for solving your concerns and needs. If it is an option, keeping your current system is usually cheaper, easier, and less disruptive on your organization. If the problem IS your reseller, then consider replacing your vendor/reseller/ consultant, you pick the title, with a new VAR that works with your product. We will use Value Added Reseller, VAR, the generally accepted term. I know this may be difficult, but many times we see a client who is trying to leave an application because the VAR simply was not taking care of them. We have found that an upgrade and training would have solved the issues for a lot less money. If you are dissatisfied, and conversations with your VAR have not helped, then contact the software manufacturer directly. They can assign you another VAR in your area. Also, check with your trade association and see whom other similar organizations are using and what their level of satisfaction is.
    
4. Define your budget and projected milestones – As soon as the TAC gets together, they need to begin building some fences around the project. The first step is to prepare a preliminary budget and compile some milestones along with target dates for completion. It is important to establish what you think you can afford to spend. Discuss other possible implications of changing applications. For instance, if you buy a new software application, will you need new servers, larger disk drives, upgrades to user workstations, what else? It would not be wise to venture forward if in fact you did not have the funds available to do so. Establishing some broad brush milestone dates help keep the project on course. Some industries have seasonal dates that are critical where you do not want your business interrupted. For instance, a public accountant would not put in a new tax application in March or April. Having a preliminary budget and milestones prepared will be helpful as you negotiate with consultants and VARs. Remember that this is a preliminary budget and project time estimate and not set in concrete. But, preparing a preliminary budget and milestones establishes parameters and lets everyone know what the playing field is! Caution, don’t take these too seriously in the beginning, or try to set them in concrete. The budget and the milestones will mature quickly as the TAC finds answers to questions and completes their initial discovery work. However, watch the budget closely as it should define what the business is willing, or able to spend. The initial budgets are always lower than the actual costs, from our experience, but you don’t want to be unrealistic. Within a short time period, depending on the scope of the project, you will know what you may need to spend.
    
5. Consider an independent consultant to assist in the project – many people go through the process of selecting core accounting application software no more than three times in their entire career, and most fewer than that. Depending on the size of your company, the scope of the solution needed, your knowledge, and the available time of you and your staff, hiring an independent consultant can be a good move. It allows you to capitalize on the consultant’s expertise and experience. The selection of a consultant should also be carefully considered. An experienced consultant can assist you in preparing your Needs Analysis, Requirements Definition and Request for Proposal. This person may not be the same person who assists you after a product is selected and you need technical expertise in the implementation process. Initially, you will want a consultant that is familiar with your industry and is unbiased and as independent of any specific vendor as possible. This person is bringing experience and expertise to help you ask the right questions, follow the right steps and prepare your written documents. Once the product is selected, you may want someone who is experienced with the product and has implemented it several times to assist you and represent the best interest of your company.
    
6. Become Knowledgeable – After a preliminary budget and milestones are established, the next task for the TAC is to become knowledgeable of what features and functions are available. Begin by making a list of all of the products you are aware of that might meet your needs. Include products that you are aware of, products you read about, products you hear about, products listed on the Internet, etc. If possible, it is a great idea to talk to others in your industry, your competitors even, and ask them what they use and add these comments to the list. So that you can evaluate the products side-by-side, you may consider preparing a spreadsheet listing key information for each product. For example, your spreadsheet might include information for modules, cost, platform, customization capabilities, certified payroll, time and billing, bar coding, and so forth. The objective here is to focus just on the most important issues and not be blinded by small insignificant shortcomings. This matrix will also be helpful in sharing information with others who may have input into the ultimate decision.

For each product you are evaluating, begin tabulating a list of the features and facts that impress you about the company and the product. For example, you may list key awards received by the product, the fact that the company provides great support, or describe a great feature that you think your company would really benefit from. Continue to add to this list as your evaluation continues. Once you have fully researched the market in your area and have a complete list, it is time to eliminate any obvious poor choices. Start to eliminate candidate products because of missing modules, missing key features, or because they are too expensive if you are sure they are outside your reach. Remember, don’t eliminate on price alone. Prohibitive as some higher end solutions may seem, they may actually help you make money, thus giving you a return on your investment. Cross vendors who are eliminated off your list and notate why they were eliminated. Keep your list, in case someone asks later why a specific vendor was not considered. Selecting the right package is mostly a process of eliminating the wrong packages. Generally, you can eliminate many products at this stage. Continue to eliminate products throughout the entire evaluation process.

As you are reviewing potential candidates, you have the advantage of the Internet. Use the Internet to research extensively. Also, remember to visit more than simply the accounting vendors’ web site. For instance, in researching the strengths and weaknesses of each of the products we present in our accounting seminars we do multiple searches using Internet Search Engines such as Google and others to find articles and comments that had been made by reviewers and users. Many of the vendors now have downloadable trial versions you can prototype before buying the product as well as case studies and references you can verify. Since the Internet is so fluid, you might want to print some of the pages you visit so that you have the information in hard copy or saved as a PDF file for reference in the future. You now have a solid list of requirements; vendors that meet those requirements and you are ready to begin more specific research of those products that have risen to the top.

7. Prepare a formal Request for Proposal (RFP) or a less formal Request for Quote (RFQ) –Small companies that are candidates for entry level accounting software solutions such as Peachtree Complete, QuickBooks Pro, or Simply Accounting do not normally need this level of detail. Mid-size to large companies however should consider seeing this process through as, if nothing else, it forces the company to formally define and describe what it expects from the VAR as well as defining the company’s responsibilities. Today, other names are also used for an RFP, such as Request to Quote, Request to Bid, or the latest term Invitation to Negotiate (sounds nice doesn’t it?) In the end, all accomplish about the same thing. If an RFP type of document is not required, at least use the Requirements Definition to present a formal document to your vendor that becomes part of your contract for services and defines your expectations.
    
8. Demonstrations of product solutions – Assuming that there are one or more vendors whose products you are interested in, it is worthwhile for you to invite them in to demonstrate their product for you. You should provide a list of 10 to 20 items or functions that you want to see that are specifically needed by your business. You do not want to see the “canned demo”. If time allows at the end of the demonstration of key items or functions, then you should ask the vendor to demonstrate items that they believe makes their product better or different. Each vendor should be able to do this in between 2 to 4 hours, but may require 6 to 8 hours. They should take time up front to ask you extensive questions about your company and your needs. They must use live software to demonstrate the product. Make sure to ask them about their available time, their installation methodology, their track record for getting the systems up and running properly on time, and a list of 3 to 5 references whom you can call to check up on their work. We recommend that you do not meet with any VARs until the Requirements Definition is complete. You don’t know what to ask for until you know what you need!
    
9. Prototype testing – We always recommends that you take the time to prototype the solution, testing it to insure it meets your specific needs. The prototyping of a product achieves a number of objectives. First, it validates the software against your data. It validates the difficulties you may encounter during the conversion stage of implementation. Prototyping allows IT to develop deployment scenarios and determines how expensive the product will be to deploy (make available to users) and support. Please do not underestimate, or skip over this critical step in the process. Even a small business should load the accounting software, enter some transactions, print reports, and even simulate a month end close to determine if the product is the right one.
    
10. Legal Considerations – Before making any final decisions and signing a contract, we always recommend legal counsel review all documents and contracts, including the on-going support agreement. Check to see how much maintenance costs you are required to pay on an on-going basis; what measures you can legally take in case the software does not work; find out who owns your data (a sly trick that some nasty vendors have employed to keep you married to them); what happens if the software supplier or VAR goes out of business; etc. I always recommend to my clients that they specify that the Requirements Definition, RFP and RFP response be declared in the final contract as being part of the agreement. You may have to update the documents slightly to include any final changes or compromises, but this is better than simply signing a contract. In nearly all cases I know of, no matter what you were told, no matter what was said or demonstrated to you by any vendor – in the final analysis you only get what is in the contract you sign!
     
11. VAR or Vendor Due Diligence – Next consider traveling to the offices of the vendor of choice and tour the company. Attend the executive briefing, and satisfy yourselves that the company has the resources and strength to meet your on-going needs. A little due diligence may go a long way towards helping you avoid a costly mistake. Before making a final decision, find out how much bandwidth and availability your VAR has related to implementing the proposed solution. If you plan to implement the system in fifty different locations, request an implementation plan depicting the time line for implementing each location and the personnel who will be used in each location. Force the VAR to think this process through before you make a final decision – else they may not be aware of availability issues that will ultimately affect you.
     
12. Contact and/or visit references – This step is often overlooked and it shouldn’t be. This stage rarely is a deal breaker. In the last decade I have had only one client get to this stage and then change their mind because of visiting an existing user. However, this step may be critical to your own successful conversion and implementation. Talking with and visiting current users will provide you insight as to how others are using the product and users are usually happy to share with you their own experiences and give valid tips so you do not make similar errors. I usually recommend calling as many references as you can but suggest three specific types. First, the user who has been on the system for at least 13 months. They have gone through a year-end! Secondly, a user in the same industry and as close to your company profile as possible. They will relate to your business, your language, and your needs best and tell you how close the product comes to meeting your specific industry needs. Finally, call someone who has had the application for 120 days or less! Why? Because they will be in the middle of the implementation and can give you a great list of things they found after the started conversion that they wish they had known before hand. This call can save you a lot of money, time and headaches. I also recommend different people in your organization call their peers in the reference company. For instance, the IT professional will ask different questions than the controller or the manufacturing floor supervisor. If each talks with their peers, writes up their responses and shares them with the technology steering committee, better decisions can be made.
     
13. The Decision – Remember that often the decision on which solution to pick is based on who is left after everyone else is eliminated. If you have followed all the steps above you should be ready to make a qualified informed decision. Keep your documentation. Make sure that all communications, including the vendor’s response to the RFP are part of the agreement you are signing. Make sure that milestones and objectives are clearly defined in the Statement of Work (SOW) so that everyone knows what is expected. Spread payments out so that the vendor still has an investment in the success of the project. Always go for the win-win. Ask yourself: would I want me as a customer, is this fair to everyone, do I know what this contract means? With all the right answers, you are ready to go forward. And the work really begins!